Maven, OSGi and JSR 277

When I read about the SpringSource Application Platform (S2AP) release a couple of days ago, a little light bulb went on in my mind. The discussion of the OSGi repository that SpringSource has put together got me to thinking that there might be a way to make OSGi development easier for everyone, by using Maven.

Wouldn't it be possible to create a simple Maven plugin which analyzed a given library (e.g. Lucene) using BND, and used the output of that to generate an OSGi manifest? You could assemble the set of Import-Package statements that you need, and then whip up some sort of intelligent algorithm that scanned the existing set of capabilities in the repository and linked in the appropriate packages in the POM's <dependency> list. It seems like this is something that could automatically be run on the existing public Maven central repository, which would lead to a very large number of OSGi packages being available in a short period of time.

Where does JSR 277 come into this? Well, several months ago Glyn Normington described an ideal solution where JSR 277's modularity aspect was done using OSGi, and a Maven-like repository that modules could be downloaded from would be created and made available as part of Java 7. Rather than a Maven-like repository, why not leverage the existing Maven central repository and add the necessary metadata into that? There are an astonishing number of libraries available in central, so it seems like there's a big opportunity there.

In the system I envision, we would have the well-known benefits of an OSGi runtime environment, the wide library selection of the Maven repository, and the dynamic availability provided by the JSR 277 module system. Libraries could be automatically downloaded, activated and deactivated, and applications could be upgraded and installed seamlessly. When you throw in other components like Service Component Architecture (SCA) and Cloud Computing, suddenly I think I might have an idea where Java will be in a few years.

Am I missing something that prevents this from happening, or is it reallly doable?

Costin Leau discusses how to turn a JAR into an OSGi bundle

Earlier this week I came across this blog entry by Costin Leau which describes how to turn a standard, run-of-the-mill JAR into an OSGi bundle. Wow - it's pretty straightforward, and there aren't any significant magical incantations involved. It's nice to see that the process for bundling up an OSGi component is so straightforward - I was afraid that there were some significant hurdles involved.

Of course, the manifest entry is probably the easiest part. I'm willing to bet that if you took most JARs that exist in existing, internal enterprise applications and ran them through the Bnd tool that Costin mentioned, that youd have a massive list of required imports. It reminds me of something Peter Kriens said in this InfoQ interview:

John Wells from BEA [..] had a presentation and he said: "we thought we were working modularly -- we were disciplined, we were doing the right thing and we were so surprised when we moved to OSGi because we found out we never had been working modularly, we had all these dependencies, all these links to all kinds of subsystems and we never noticed it because it was all on the classpath, and as long as you didn't use it you didn't run into the problem"