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?
3 comments:
Well, there is a Felix Maven plugin that does just that. And it is based on bnd, and it works.
However, unfortunately automatically wrapped libraries are a bit crude. Because libraries have been developed without modularity in mind, they often refer to everything and the kitchen sink. I.e., when you download maven and create an hello world, for some reason you download the Wicket template library.
In OSGi you would not be able to run the bundle until all dependencies are resolved. Many of the dependencies are just necessary in few occasions. E.g. bnd itself has a dependency on ant because it runs as an ant task. However, when you run it as a bundle it is not imported because in that context it does not require ant.
Even though I think I could analyze these situations in bnd, I just do not have the time (it is after all a free product) to add that functionality. This means that the only "easy" way is to just import all the dependencies with optional resolution. There are also other issues which still require human eyes. Many libraries are quite messy from a modularity point of view.
Kind regards,
Peter Kriens
Interesting - I can see how there would definitely be a tradeoff between automation and human intervention, but at the same time it seems that by doing some compiler-like analysis and branch prediction it would be possible to determine required versus optional dependencies.
It should also be possible to detect things that often break under OSGi, such as Hibernate and Log4J - I don't imagine it would be possible to automatically fix those sorts of issues, but it would be very useful to know that they exist so that the process of OSGi-ifying a library was easier.
If I've interpreted your comment correctly, then you believe that this is possible given time and effort - is that fair? I definitely believe that this sort of tool would make writing an OSGi-compliant application/library easier, which would in turn lead to broader usage and adoption of OSGi in Java development.
Thats a really cool idea Ryan.
Post a Comment