views:

180

answers:

2

I've been looking into OSGi for a while and I'm wondering about the best way to deal with "legacy" libraries (that are released as plain JARs, not as OSGi bundles).

What do you think is the best way to handle these? Modifying their manifest file and adding the minimal bundle-specific information, then repackaging them is what I do at the moment, but it seems somehow wrong to me. Should I just use manual dependency management for these JARs (I do this for those libraries which have a high probability of being used only in a certain part of my application)?

As far as they are available, I'm using bundles for Eclipse (since I'm using Equinox as OSGi platform, this works out well for those libraries that are available as bundles).

Are there any bundle-repositories besides the Eclipse-bundles that I should know of?

+3  A: 

Spring is going OSGi in a big way, using Equinox as the underlying platform.

http://www.springsource.org/dmserver

Rob Harrop's blog is worth following if you're into OSGi developments.

And to answer your question, here's Spring's OSGi bundle repository:

http://www.springsource.com/repository/app/

skaffman
A: 

There's also Eclipse Orbit which has a number of pre-packaged bundles for Eclipse's uses. And instead of amending the bundle's manifest directly, you can create a wrapper bundle which provides the Manifest yourself, and include the Jar as is with a Bundle-ClassPath: foo.jar header. It's slightly less efficient to do it this way since at runtime, the foo.jar is extracted out (at least, on Equinox) but it might be easier for you to manage the build process with that.

The Spring repo is also a good source of open-source libraries that have been OSGi'ified.

AlBlue