Releasing for JSE, NetBeans Platform and OSGi in a Single Shot

With the upcoming release of jrawio 1.6, I'm starting to release the artifacts in three versions:

1. an artifact for inclusion in standard JSE projects, that is a jar that just needs to be put in the classpath
2. an artifact to be used in the NetBeans Platform, that is a nbm that contains some information in the manifest that, among other things, describes which packages are exported
3. an artifact to be used in an OSGi container, that is a jar with some information in the manifest similar to those for the NetBeans Platform; in this way, people working e.g. with Eclipse RCP can integrate jrawio in their projects.

Actually, artifacts #1 and #3 are the same file that can be used in both contexts. Probably in future I could be able to have this single file to serve also for case #2 (see the discussion at the end of this article), but today it's not the case.

In this post I'm going to describe how I managed to achieve those goals with a Maven project.

As as side note, I think this could be my first post about Maven. In the past I've frequently expressed my disappointment about Maven and its complexity. While I'm still keeping the same arguments, and in addition - having worked with it for some months now - I also found many traces of bad design and implementation, I've resorted to converting my projects from Ant to Maven for a number of reasons, including the fact that Maven provides plugins ready for delivering in the NetBeans Platform and OSGi environments. A more comprehensive discussion about Maven from my own perspective will come in future when I've finished the migration of all my projects.

First, let me quickly introduce the structure of the jrawio project from the software building point of view. It is composed of two plain JSE modules, named "codec" and "processor", with the latter depending on the former. While releases earlier than 1.6 distributed two artifacts, one per module, starting from 1.6 there a single artifact is released; nevertheless, I kept the sources in two separate modules because they are different enough to be considered two different components.

In the rest of the article I'm assuming that the reader has got basic knowledge of Maven, the NetBeans Platform and/or OSGi.

Ok, before going on one might ask: why are you doing this? Answer: because it seems to me that component frameworks are getting momentum. The NetBeans Platform makes it possible for me to build complex projects such as blueMarine; OSGi is getting more and more popular, and with Java 7 we will have components integrated in the JDK (in a way or another). So far, the common practice is that people release plain JSE libraries, and developers wanting to integrate them into a component framework do the needed work (for instance, with the NetBeans Platform, by creating a wrapper module). But why delegate this job to users? It's a silly way to waste time, as everybody will do more or less the same thing. It's better that the library provider takes charge of this step, also because the library provider can control in a better way what is put into the manifest metadata.