I believe the next few years are going to be an extremely exciting and productive time for the Eclipse ecosystem. I say this not only because I’m an optimist at heart, but also because there are large scale forces pushing things in this direction.
The modular convergence
The way I see it, some of the large pieces of the software puzzle are converging on a single way of seeing the world. The reason for this convergence is the increasingly obvious benefits of modular software development. So what’s converging?
- OSGi is at the heart of this this process. It’s the glue that holds everything else together.
- Eclipse, meaning the entire ecosystem and not simply the IDE, has obviously been using OSGi for quite a while, but this usage is becoming increasingly explicit.
- Maven has become increasingly focused on OSGi due to obvious synergies in versioning, dependency management and provisioning. I think it’s fair to say that OSGi is going to be a core part of Maven going forward.
- Spring has also made a big bet on OSGi, starting with Spring DM and Spring dm Server. Spring also uses the Eclipse IDE as the basis for it’s development tools and Maven as it’s build solution.
As these technologies continue to become more interrelated, the benefits of using them together is going to increase dramatically. I don’t think it’s too far-fetched to say that these technologies will coalesce to form something like a new new LAMP-style stack for Java development.
What does this mean for Eclipse developers?
It’s in the interest of the Eclipse community to promote this convergence in any way it can. As developers, we should be looking for ways to speed up the process and also take advantage of the resulting synergies. Specifically:
- Eclipse should embrace OSGi as explicitly as possible, in many ways this is already happening. We’re seeing more and more OSGi standard services shipping with Eclipse runtimes and also increasing usage of OSGi services, particularly in the work being done by the e4 team. Another good example of the renaming of the Plug-in Development Environment to the Bundle Development Environment. These changes are a good start, but let’s see how far we can push this.
- When it comes to Maven, the story is unfortunately different. Builds are causing a lot of pain for Eclipse developers, and the quickly multiplying build tools (PDE Build, Buckminster, Athena, B3) are causing some confusion. My questions is: if Maven and Eclipse are both converging based on a shared interest in OSGi, why not focus on Maven as the solution to our build problems?
- Spring is a technology that is not commonly used in Eclipse projects, but it’s focus on OSGi-based modularity would make it a perfect fit. This would also be true for those consuming Eclipse projects, such as Rich Client Platform developers. There’s actually not a lot of technical work to do here, just some evangelization. Spring and the various Eclipse projects have a lot to offer each other, and we should start to take more advantage of this.
Speeding it up
In my opinion, the decision to make OSGi the foundation of the Eclipse ecosystem was one of the best decisions the Eclipse team has ever made. This decision has made it possible for Eclipse to participate in the convergence now taking place, but there’s more work to do. The actions we take now can slow the process down or speed it up. I say we take every opportunity to integrate with those who share an interest in modularity and OSGi. We’ll all be better off for it in the end.