blog:eclipse_way_core_values
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
blog:eclipse_way_core_values [2014/11/19 08:28] djo [Combining Eclipse Way with XP and Scrum -- a Case Study] |
blog:eclipse_way_core_values [2018/02/01 11:13] djo |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Combining Eclipse Way with XP and Scrum -- a Case Study ====== | ====== Combining Eclipse Way with XP and Scrum -- a Case Study ====== | ||
| + | |||
| + | //[Updated with light edits; February 1, 2018]// | ||
| In our previous installment, I gave Eclipse another shout out for their amazing perfect track record of shipping on time for 13 years. I then described how I had the privilege of working with a team that, by intentionally adopting practices from Eclipse Way into our XP/Scrum process, achieved a similar perfect track record over a period of four years, shipping every six weeks, with only a single emergency bug fix release. | In our previous installment, I gave Eclipse another shout out for their amazing perfect track record of shipping on time for 13 years. I then described how I had the privilege of working with a team that, by intentionally adopting practices from Eclipse Way into our XP/Scrum process, achieved a similar perfect track record over a period of four years, shipping every six weeks, with only a single emergency bug fix release. | ||
| Line 24: | Line 26: | ||
| Steve Northover, the "father of SWT", (the Eclipse GUI library) likes to say, "API is forever and @deprecated is a lie; somebody will always depend on your code". | Steve Northover, the "father of SWT", (the Eclipse GUI library) likes to say, "API is forever and @deprecated is a lie; somebody will always depend on your code". | ||
| - | The article [[http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html|How to use the Eclipse API]], while deprecated as-of this writing in my opinion still provides valuable perspective on API best practices. In addition, Eclipse's wiki contains several articles on [[https://wiki.eclipse.org/Evolving_Java-based_APIs|Evolving Java-based APIs]] with detailed information for practicioners interested in building strong API guarantees into their products, even if they are not building on top of Eclipse or OSGi infrastructure. | + | The article [[http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html|How to use the Eclipse API]], while deprecated as-of this writing in my opinion still provides valuable perspective on API best practices. In addition, Eclipse's wiki contains several articles on [[https://wiki.eclipse.org/Evolving_Java-based_APIs|Evolving Java-based APIs]] with detailed information for practitioners interested in building strong API guarantees into their products, even if they are not building on top of Eclipse or OSGi infrastructure. |
| API is a deep topic and worth much more than this brief introduction. If there is demand, I can write more about that. | API is a deep topic and worth much more than this brief introduction. If there is demand, I can write more about that. | ||
| Line 31: | Line 33: | ||
| In addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies. And the container enforces these dependencies at run-time. | In addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies. And the container enforces these dependencies at run-time. | ||
| + | |||
| + | What does this mean? It means that OSGi sandboxes each plug-in with its own classpath. In addition, a given plug-in's classpath is isolated to just the libraries that a plug-in depends on, and not dependencies of dependencies. Since plug-ins do not see transitive dependencies among each other, this minimizes conflicts caused by dependencies of dependencies depending on differing versions of the same library and enables plug-ins to be evolved independently of each other by multiple teams around the world. | ||
| + | |||
| + | While this approach doesn't solve every problem related to "jar version hell", it goes a long way toward keeping differing teams from breaking each others' code when they change their dependencies or dependencies' versions. | ||
| We obtained substantial benefit by using Eclipse's OSGi container. Non-Eclipse projects may wish to consider [[http://karaf.apache.org/|Apache Karaf]] as an alternative. | We obtained substantial benefit by using Eclipse's OSGi container. Non-Eclipse projects may wish to consider [[http://karaf.apache.org/|Apache Karaf]] as an alternative. | ||
| - | However, while we realized substantial gains by using an OSGi container, I believe that disciplined adoption of Eclipse's API conventions can realize significant modularity gains, even when implemented outside of an OSGi container. | + | That said, while we realized substantial gains by using an OSGi container, I believe that disciplined adoption of Eclipse's API conventions can realize significant modularity gains, even when implemented outside of an OSGi container. |
| Lastly, this blogger would encourage the Java community to evolve a solution that unifies the current dichotomy between Maven's dependency architecture and OSGi/P2's. | Lastly, this blogger would encourage the Java community to evolve a solution that unifies the current dichotomy between Maven's dependency architecture and OSGi/P2's. | ||
| Line 98: | Line 104: | ||
| In this article, I have reviewed four key Eclipse Way practices that in my experience work very nicely in tandem with practices from Scrum and XP. In a previous job, these practices synergized into a process enabling our team to consistently deliver quality software with new valuable features, on time, every six weeks, without stress. I have delivered this as a case study because I believe that this success can be replicated, and in combination with best practices from XP and Scrum can result in high-value software delivered consistently on-time, at or under budget. | In this article, I have reviewed four key Eclipse Way practices that in my experience work very nicely in tandem with practices from Scrum and XP. In a previous job, these practices synergized into a process enabling our team to consistently deliver quality software with new valuable features, on time, every six weeks, without stress. I have delivered this as a case study because I believe that this success can be replicated, and in combination with best practices from XP and Scrum can result in high-value software delivered consistently on-time, at or under budget. | ||
| - | ~~~DISQUS~~~ | + | |
blog/eclipse_way_core_values.txt ยท Last modified: 2018/02/01 11:37 by djo
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution 4.0 International
