maven

This weekend Richard S. Hall and his wife Ya-Ching visited us. We picked them up from Nîmes train station after which we had an original French lunch under the city trees. I am pretty sure not enough of this was spent on Richard and me because obviously we had a lot to discuss. To my shame I must admit we probably bored our partners to death with our lingo. Fortunately my wife is hardened after watching me talk shop for over 26 years with hundreds of technical guests.

Though we had lots of subjects we wanted to discuss, it often turned back to Richard pressuring me to become an Apache Felix committer (Ok, I wore my Eclipse committer shirt). So during the weekend we download the Apache Felix source code on my disk. The first hurdle was maven, so far I resisted maven because ant, its predecessor, has always left me with a bad taste in my mouth. However, Apache projects are more or less forced to use maven because it provides an interesting shared repository model, which is obviously crucial for an organization like Apache. Unfortunately, the repository architecture is based on simple hard references instead of the more powerful capability/requirement model of the OSGi bundle repository.

The interesting approach of maven is that it does not try to be a scripting language (which ant tried) but that it works with a declarative model. Project rules are defined in a central place shared between different products while products only declare information. This looks very familiar to me because that is how I always used make (and also later when I was forced to use ant). Redundancy is the root of all software evil, and most ant files I have seen are so redundant because of their copy-paste history that they put Lucifer to shame. Maven addresses this issue by rigidly specifying a project directory structure, which is excellent.

In Maven, each deliverable needs a pom file. A pom file is, you guessed right, an XML file. How anybody can use XML for a human writeable/readable format escapes me, but it has taken epidemic forms. Not sure it is caused by CS students not reading the Dragon Book, or that there are too few CS students writing open source software? Anyway that was enough ranting. The pom file describes the unique facts of your deliverable and its dependencies. Maven reads the pom file and provides this information to the overall shared rule set that then builds your product accordingly.

A crucial aspect of maven is dependency handling. The pom file refers to dependent JARs by a symbolic name. A URL based repository is used to retrieve those dependencies automatically when needed. This works fairly well though I had some troubles operating offline (and the dependency set is amazingly large, I think it downloaded the whole of Apache, though we might have missed Geronimo).

Maven provides a plugin model for special actions. Plugins are activated from the pom file and can access the information in the pom file. Enrique Rodriguez created a special Maven-OSGi plugin that handles the OSGi required manifest entries. When we looked to this I noted that the pom files also contained the import package clauses. This is of course a maintenance nightmare because they depend on the actual code. I recently had written a certifier that basically contains all the required code to calculate the imports, and much more. So I indicated to Richard that it would be a couple of hours work to automatically generate this information. The advantage of Java class files is that they contain so much information.

This sounded like fun so we added the imports. This turned out to be so easy that we decided to do some extra checking. We verified the export statement, we detected bundle activators and allowed them to be automatically set, and we added the hard to write yourself “uses” directive on an export. Obviously we took care to be backward compatible, if you specified the header in the pom file, we verified it. Otherwise we generated it. This is all pretty complex stuff but it went amazingly smooth. I have released the code to Felix so now the Felix community must take a look and see if it fulfils their needs and quality requirements. I guess that is going to be the hard work.

Doing this was just a fun exercise; I always enjoy doing these joint exercises because you learn so much working with someone else. Explaining to our partners that this is more fun than enjoying the sunny weather with them was the hard part.

Peter Kriens

P.S. The OSGi Alliance has a public webinar the Thursday 27th of April. Please join us for information about the new membership class, plans, and the possibility to ask the questions about the OSGi Alliance you were always afraid to ask.

P.P.S. For JavaOne I am still looking for 2-4 slide presentations.