There has been a lot of positive press about Eclipse’s Callisto effort, heralding it as an “Agile Success Story”.
I’m surprised by the entusiasm of Eclipse users, considering it appeared to cause a delay to the release of Eclipse 3.2 itself, and didn’t deliver any new features.
It certainly seems to have been a success by their own measure – let’s face it, releasing and managing that much code and that many committers is no small task. It yet again proves that open source development can prove to be very effective.
However, I must admit that my original reaction was to ask why it was needed. This, surely, was a failure of modularity. I’m not particularly familiar with Eclipse platform development, but today I read that Peter Kriens, an OSGi evangelist (which is the component technology upon which Eclipse’s architecture is based), shares a similar sentiment.
Building componentised software is a funny thing. It’s conceptually very simple, but in practice it is usually quite difficult. It requires forethought, discipline and consistency. This is certainly something that is more difficult to achieve in large systems.
It is disappointing that Eclipse, the most popular IDE for Java developers right now, went down the path of the big bang release rather than working towards a goal of better modularity and offer those experiences and tools to other Java developers.
Like it or hate it, one of the reasons for Maven’s existence is to promote best practices, and we like to particularly focus on making component-based development easier. While I freely admit it’s not a problem we have come close to solving, I certainly think we’re moving in the right direction. Particularly in the area of transitive dependencies we’ve only seen these used widely in Maven for the last year and a lot has been learned in that time for the next installment.
Peter offers some possible reasons that Eclipse development has failed on this count. While the initial reasons make sense (at least to me as someone unfamiliar with PDE development), he then moves on to the OSGi purist’s favourite sport of beating on Maven’s dependency model.
“I hate to bring it up because I feel like a zealot, but obviously the
require bundle is a clear symptom of this world view. Require bundle is
the transitive dragnet of software. It is easy to use and you are
likely to catch the code you need. However, just like a real dragnets
you catch lots of fish you do not need. Worse, due to its
transitive nature that stuff in your net is connected to lots more
stuff you do not need, ad nausea. Look at Maven, it uses a similar
concept and has to download about 30 Mb of software before it can build
your “hello world” that has no dependencies except that is build with
Maven.”
So, first to correct some facts: Maven downloads just 2.7Mb of software to create, compile, test and package it’s “Hello World”, all of which is Maven plugins and dependencies. This is simply because Maven chooses not to distribute everything with the original download like Eclipse does, and has nothing to do with how the application itself chooses to select it’s dependencies.
For those unfamiliar, OSGi and Maven aren’t really similar technologies, nor are they in any way mutually exclusive. Maven is not an application execution framework (the closer analogy to this aspect is Maven’s container, Plexus), and it is certainly possible to build OSGi software using Maven. The area that they do overlap on is their dependency management capabilities (Maven at build time, and OSGi at runtime).
I’m not an OSGi expert, but here is my understanding of the differences between what is recommended in the blog and “require bundle”.
OSGi has two concepts in this regard for declaring a dependency: Import-Package and Require-Bundle (a recent addition to the OSGi spec, introduced in R4 last year). These reflect two units of use – a Java package, and an OSGi bundle (which can be though of as a total Java JAR). In Maven, the latter unit of dependency is the one used, though I believe that Maven (and others that are similar like Ivy) contain a number of features that can’t be used in OSGi’s bundle resolution.
In some ways, OSGi’s original approach certainly makes more sense – it ensures that the development model is not confused with the deployment model. You could put a package into 10 different combinations of JARs and the dependency model, I presume, behaves the same. However, this comes at great cost to the OSGi container implementor, with class loading gymnastics aplenty required, and it isn’t without impact on the developer.
There are a number of reasons I prefer Maven’s approach in general for dependency management and think it can help with modularity in Java development, but that’s a topic for another day 🙂
Back to Callisto, I’ll be interested to see what the near and long-term future holds. Has it helped plugin developers overcome version management issues? Will users expecting new features or additional stability from all the hype be disappointed? Will it improve delivery and stability, or will it become viewed as a painful roadblock?
Technorati Tags: maven osgi eclipse callisto
Brett Porter