How to package and consume an existing Java library with OSGI

After asking for help for managing dependencies on different versions of the same libraries in Java, it was suggested that I should take a look at OSGI implementations. Being under a deadline pressure, I cou开发者_C百科ld really use some help that would save me from digging through endless OSGI docs. I have a working app, which is going to use a new framework. The framework uses different versions of jars that I'm already using, so I want to package the new framework as an OSGI bundle. Can I leave my app as it is, and use the OSGI bundle only as a container within JVM? This would mean I would be using OSGI bundle only to isolate a set of classes from the rest of the JVM to avoid conflicts between different versions of classes. in other words, I want to use OSGI without carrying all my code to an OSGI based setup.

Kind regards Seref

---

I do not have a complete answer for you here, I just wanted to counter what deterb said:

First, you have to have your entire application within the OSGi framework.

That is not true. Another approach would be to embed an OSGi container into a host application.

The tricky part here is the interaction between inside of OSGi and outside, because the code lives on separate classloaders.

You can make your host classes visible to the OSGi part using the OSGi system classpath. The other way around is more difficult.

One way for host code to interact with bundles is an interface that is visible to both the host application and the bundle, i.e. part of the host. Another way would be to use reflection.

If you have a clear separation between host and OSGi, for example a plugin system, then this could work quite well.

Being under a deadline pressure

That could be a problem. There is a lot to learn with OSGi, and since it is just about to hit the mainstream, there is still a lack of community knowledge, tool support, library compatibility, and so on.

The biggest question you should ask at that point is: Do I really need to manage different versions of dependencies at runtime? If not, i.e. you can figure things out at the time of deployment (for example by configuration), then there may be a simpler solution for you.

---

First, you have to have your entire application within the OSGi framework. However, I don't think it would be difficult to set it up so that you only have to work with a few bundles (perhaps only two, depending on your setup.

The path with the fewest issues I can see would be to take the framework and "wrap" it and all of its dependencies in a single bundle. Make the packages for the dependencies private. For your main project, do the same.

The other path would be to package all the libraries separately using the appropriate wrap commands. This has significantly more potential issues if you're not interested in going full OSGi.

Depending on your build setup, I would look start by taking a look at the maven-bundle-plugin and/or Bnd. The maven-dependency plugin makes it pretty easy, as all you have to do is tell it which artifact-ids to embed and it'll do it. You will need to make sure you specify all of the embedded jar packages as private packages.

This should work unless the framework is doing class loading/AOP, which would make it significantly more difficult to OSGify.

Finally, if you're interested in a quick non-osgi solution, build the framework with the maven-shade-plugin and just rename all the packages for the conflicting libraries. This would probably be the easiest as you'd just repackage the framework with the shaded libraries once and then use that as your dependency.