Eclipse Callisto: Success or Failure?

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

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:

5 responses to “Eclipse Callisto: Success or Failure?

  1. So eclipse is very modular and you can install whatever versions of things you need.

    The power of Callisto is that once you have hundreds of eclipse components (developed at, spread around many different repositories – it can take a while to choose what you need and install them all. So really its just about having a shared repository really 🙂

    The big win of Callisto from an eclipse user (and ex IntelliJ user too 😉 is that at last all the dependencies of things like WTP are in one repo – whereas before the common base plugins like EMF and GEF were not even in a repo causing heaps of manual download.

    The added bonus of Callisto is it provides a simple single version number that folks who use most of Callisto (eclipse + WTP + BIRT + Data Tools + TPTP say) don’t have to play version bingo, but can just upgrade to known, compatible versions

  2. Hey James! It’s interesting that you put the “get it all in one place” argument as the best thing, and the “known, compatible versions” argument as an added bonus, as most of the Callisto hype I’ve read has been focused on the latter.

    These are both good things, though I’m not sure that simultaneous releases are necessary to achieve the first goal.

    As for the known compatible versions – that was really my point – certainly a good thing to have, but why is it necessary in a well modularised architecture?

  3. …because, even in a “well modularized environment”, you still have to worry about interfaces between modules, common documentation practices, etc. I wouldn’t view this as a failure of modularity as much as an attempt to synchronize effort and resources across multiple groups. I see this more as an attempt to galvanize the people involved and focus the effort.

  4. Maven can build easily and with success OSGi based softwares, even Eclipse based applications.
    OSGi allows you to have many and many modules in you apps, Maven able you to handle them all together

  5. It would be nice if Maven were just run as a set of plug-ins but on the Eclipse framework. Not that plexus is a bad thing.

    The intent is to remove more code from Maven and offload the maintenance of it to other opensource projects.

    A side effect of this would be Maven can work as a plug-in in Eclipse as part of its core feature rather than an afterthought (e.g. mevenide or maven-eclipse-plugin). Those two projects are great, but can get out of sync with the rest of Maven.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s