To Build or not to Build, that is the OSGi question

There are two huge Open Source organizations that have recently adopted OSGi: Eclipseand Apache. They both have their own highly active mailing lists. Interestingly, a lot of the usual OSGi suspects are arguing their cases there: Jeff McAffer, BJ Hargrave, Richard S. Hall, and others. Currently there is an interesting debate going on about builds.

A build is all the stuff you need to create a bundle from some Java source code and resources. Builds are torn between two optimizations. When you download a project in source form, you clearly do not want to spent hours figuring out how a build works. It should therefore be simple and small (actually just like all software).

A big issue with builds is how it is coupled to the environment. I have seen some horrific builds in my time. Invariably the problem is that the build is closely intertwined with the environment and/or highly redundant.

The top mistake is that the build file contain hard code path names like c:\projects\bundles\http. A runner up mistake is redundancy. Quite a few builds have a project build file that is more or less verbatim copied from one project to another, just the tiny 5% with the hard code path names are changed to reflect the new project. Adding build rules to a large multi project is painful.

In the old days we had Make, Make was replaced by Apache Ant for two reasons. First it had a brain damaged way of handling tabs that was hard to get your head around without Emacs, and second, too many people were under the impression that make was script language, which it definitely is not: it should be a declarative description of a project.

Ant was developed for Java. It added the nice features that it was running on all environments that Java was running on. Unfortunately, too many designers abused ant in similar ways as they did make files (they never learn!) so too many ant builds have also become a terrible mess.

So the discussion on the felix mailing list is discussing the build of the Felix bundles. There are two interesting solutions that both require work. Eclipse desires to be the primary bundle development environment. However, Eclipse is not the only player in town, developers are surprisingly picky with their right to choose their own IDE. From vito IntelliJ IDEA. Especially the open source cowboys need their freedom, so a purely Eclipse solution is not acceptable.

Maven is the answer from Apache Foundation. Maven takes the approach to define a standard project structure. The predefined structure is parameterized with an XML file, plugins provide the rules. There is a special OSGi plugin for Maven that handle the OSGi related artifacts like the manifest. I have not worked in detail with Maven but at first sight it seems to be clean.

It will be interesting to see how the build will finally look like in Apache. And even more interesting to see how Eclipse will start making bundles. Interesting times.

And for my own build? For my customers and the OSGi Alliance I have over the past 8 years developed my single shared build file and of course btool! However, maybe one day, if Eclipse or Apache comes up with something better, I might change. How do you handle your build?

  Peter Kriens

osted by Peter @ Monday, December 05, 2005