There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.
There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.
The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.
So for some of those reasons you mentioned is why I subscribe to the “manifest-first” driven form of OSGi development. I believe that YOU have to handcraft your bundles to get things right… there are too many variables.
Everyone has a right to an opinion though 😉
I agree. And I have to add that OSGi-fying is not only adding some manifest headers: We have got valid bundles then, OK. But where are the services? Without services we only use half the power of OSGi. Let’s look at Pax Logging as an example: There is logging API and there is a logging service. Only the later will give us the full power and flexibility.
I agree with this on the whole, but not Chris’s conclusion that only handcrafted manifests will do. I think there’s clearly a middle ground and Bnd gets pretty close to the ideal: the error-prone repetitive stuff is generated but we have a chance to guide and customise the process using the Bnd descriptor.
Are SpringSource _really_ saying they can automatically generate bundles with no intervention? I use Bnd to bundleise libraries but always have to supply some metadata (e.g. making some imports optional, tuning the versions, etc.). Bundlor looks similar and I think they followed a broadly similar process to produce their repository.
I need to evaluate Bundlor properly, I’m cautious that it may require evil Springisms like Import-Library.
Neil, the way I read it and because of the bundle quality in the SpringSource repository I doubt that they took the time to review the generated meta data.
At least the springsource OSGi bundles for EclipseLink work as expected. Unlike the newest EclipseLink OSGi bundles that I can not use together with dynamic-jpa.
To my surprise there is still a 3rd layer needed to get database stuff working the OSGi way. Dynamic-JPA does what EclipseLink and other OSGi’fied JPA bundles should do already. Provide the persistence units EntityManagerFactory as services. Allow dynamic additions of Entities to those factories through the means of Entity OSGi Services or Bundle-Headers. Allow the configuration using OSGi ConfigAdmin. I mean I wonder how one can seriously use JPA in an enterprise environment when you have to hardcode your JDBC connection settings into the persistence.xml.
Philk, totally agree. The whole ORM stuff needs a better OSGi story. I didn’t know Dynamic-JPA before. Thanks for the tip.