Eclipse has earned a reputation of being one of the best IDEs in existence. While it has become a lot more than that in many ways, its roots and its focus have always been the user facing aspects. That is probably the reasons why certain other aspects like the PDE build have been a bit neglected for quite a while. Between the ugly map files, the dependence on a target platform and its disability to run JUnit 4 tests it feels like there is quite some room for improvement.
I appreciate all the effort that went into the current state of the PDE Build, and there is quite a lot that it offers: Checking of OSGI access rules, validation of extension and extensions points, multi-platform builds, generation of p2 metadata for update sites among other things. I want to take a look at some of the recent and ongoing developments that build upon that legacy.
The b3 project is currently in incubation at eclipse.org. Its goal is basically to be to the PDE build what p2 was to the update manager: A revised, more powerful version of one of the main components of the Eclipse Platform. But while p2 was more or less a complete rewrite, the key with b3 idea is to build upon the exisiting technologies like the PDE build core, Buckminster, EMF and P2. Important key aspects are extensibility and customizability. as well as interoperability with other build tools such as ant and maven.
It is refreshing to see the build process getting more attention as of late, and that the Eclipse community itself is stepping up to the task of making sure that Eclipse based applications are built in a simple, repeatable and reproducible manner.
While Eclipse is certainly one of the defacto industry standards, another one is maven. Just as Eclipse is more than an IDE, maven is more than a build tool. The Tycho project is the maven implementation for building Eclipse plugins. While there are currently maven plugins out there capable of building “plain” OSGi bundles, Eclipse plugins are quite a lot more involved. Since both the maven pom.xml and the OSGi manifest include dependency information, there is a bit of redundancy here. The idea is here to have one of these be the “master” version, and then synthesize the other one from that. This means that projects can either be “pom-first” or “manifest-first” depending on the sepcific requirements and project setup.
There a certainly some roadblocks in the way. For example, both OSGi and maven have a concept of versions that is important for resolving dependencies. And while their format is superficially the same, their notion of version ordering is subtly but definitely incompatible. This can lead to all kinds of havoc.
Hopefully issues like these will be resolved sooner rather than later. Eclipse is not an island. Many applications based on Eclipse RCP are actual rich clients, which means they are connected to a server. These server components are usually more traditional “read: non-OSGI” Java applications, and thus tend to be built by a maven setup. In cases like these it would be desirable to have client and server share the same build infrastructure. This would be a huge boon to many real-life projects out there.
Both these projects show an encouraging amount of progress, and I am convinced that these efforts will go a long way in making the Eclipse and the Java Platform an even better combination. While I think friendly competition is a good thing, competitive cooperation can be even better. Maybe these two projects have slightly different goals and will fill slightly different niches in the future. But I believe there is a lot of common ground, and I hope there is some healthy cross-pollination between these two projects, if not more. Both teams have a quite a background in their respective areas, and thus could bring a lot to the table.
I for one am looking forward to see these two project bear fruit, making the Eclipse build process a lot less painful and a lot more powerful.