Eclipse and the modular convergence
October 26th, 2009 | Published in Ramblings, eclipse | 5 Comments
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.
Patrick on the RCP Panel at EclipseCon
October 26th, 2009 at 12:02 pm (#)
In the last two releases, the improvements made in the separation of concerns between PDE build (to compile stuffs) and p2 (to assemble the product) got us closer to using another build technology, and this was intended.
In fact, we discussed the idea of tossing PDE Build to the benefits of Maven, unfortunately there are several issues at stake:
– Resources. PDE build is working, there are higher priority items in the SDK to be addressed.
– Backward compatibility. For the users, changing without anyone noticing or breaking could be hard, let alone of extenders (Athena, b3)
– Loss of control. The ability to ship PDE build in the SDK and its ownership gives the team a lot of flexibility and thus an ability to quickly turn around when shit happens.
– Functionality. Are we trading one set of problems for another one?
None of those are insurmountable, we could likely ship with Maven and PDE Build and become committers on Maven or parts of it. The really hard one is which company or individual does this problem hitch enough so it takes on the responsibility of providing a solution to it. But btw, what is the problem to be solved? There is already Maven Tycho which is here to build plug-ins?
October 26th, 2009 at 12:08 pm (#)
>This decision (to make OSGi the foundation of the Eclipse) has made it possible for Eclipse to participate in the convergence now taking place
You are reading the history backward :) Eclipse has been the tipping point of OSGi and is what took it mainstream. It made significant changes to the spec (ids to bundles, fragments, etc…) making it relevant outside of the niche where it was.
October 26th, 2009 at 1:52 pm (#)
Hi Pascal,
Thanks for adding your thoughts. First, I agree that Eclipse drove the adoption of OSGi and everyone involved should be applauded for the work they’ve done to make it happen.
Also, I understand your reasons for sticking with in-house build solutions and I hope that the Maven people can make Tycho a viable alternative. I guess what I’m asking people to do here is take a long-term view of the situation. In my opinion, Maven will become the de-facto standard for OSGi-related builds. Everyone will expect, if they don’t already, that the default build story for Eclipse projects (especially runtimes) is based on Maven.
My point is that if we should do everything we can to make Maven builds easier, and I know we’re doing some things already. Off the top of my head, we may want to make our project shapes more compatible with Maven. We may also want to think about creating Maven plug-ins to do various Eclipse-specific things. The code would still be under our control (for when shit happens :)), but it would run under Maven.
Ultimately, I think that having a Maven-based build would really increase the adoption of Eclipse projects. A lot of people who kick the tires of Eclipse RCP in particular are put off by the difficulty of the build process. PDE Build is working technically, but it’s not really working from a marketing point of view.
Regards,
— Patrick
October 30th, 2009 at 5:29 pm (#)
Puzzled by your comments about Maven, and in general.
There’s no central steering committee (nor should there be) to kill off technologies that may “confusion” for someone. That wouldn’t exactly be a path to technical innovation. Anyway, code talks, and the community decides whether to listen.
Also, when you understand what the projects you mention actually do, you realize they’re all doing something different. I’d like to see projects work together. That’s what I want as a user. Let’s leave the attempts to create proprietary monocultures to the big commercial vendors!
November 2nd, 2009 at 10:46 am (#)
Hi Michel,
Thanks for the feedback. I don’t think we’re actually that far apart in our views. I’m definitely against centralized control and killing off technologies that may be useful. As for a monoculture, the only one I see is that we agree on OSGi as a solution for modular software development.
I do think, however, that we should be working harder to cooperate with projects across organizational boundaries. In particular, there is a lot of good that could come from the Apache and Eclipse foundations working together on OSGi related runtimes and tools.
— Patrick