OSGI - handling 3rd party JARs required by a bundle

Question

I'm just getting started with OSGI development and am struggling to understand how best to handle dependant JARs.

ie if I'm creating a bundle the likelyhood is that I will need to use a few 3rd party JARs. When I create my bundle JAR to deploy to OSGI, obviously these 3rd party JARs are not included and thus the bundle will not run.

I understand that one option is to turn these JARs into bundles and also deploy them to the OSGI container. However if they only need to be used by the one bundle this doesn't seem ideal.

What is the best solution to this? Can the JARs be embedded within the bundle JAR and if so is this a reasonable approach?

Answer 1

You can include a third party jar inside your bundle by adding the third party jar to the root directory of the bundle jar file and then adding a bundle classpath header to the bundle's manifest, eg:

Bundle-ClassPath: .,my3rdparty.jar

If you want to place third party jar to subdirectory, specify the path without using heading ./ , eg

Bundle-ClassPath: .,lib/my3rdparty.jar # (not ./lib/my3rdparty.jar)

Answer 2

I would almost always bundle each jar separately. OSGi itself is meant for modularization and you take the whole system ad absurdum by not doing this.

If you want to convert JARs into bundles you might want to use the BND Tool written by Peter Kriens . But first I would suggest you look for the bundle in the SpringSource Enterprise Bundle Repository if they haven't already done the work for you.

Answer 3

It is possible to embed non-OSGi dependencies into the bundle.

An easy way to do this is to use Maven to manage your dependencies and Maven Bundle Plugin to build your bundle. Take a look at the <Embed-Dependency> and <Embed-Transitive> instructions of the Maven Bundle Plugin described in the section Embedding dependencies of the plug-in documentation page.

As Roland pointed out this is not an ideal solution with respect to the intentions of OSGi, ie modularization and reuse of individual modules. However it might be pragmatic solution for time being until the 3rd-party dependencies can be converted into OSGi bundles.

Answer 4

This thread is a bit old, but I wanted to point out one of the limitations of embedding dependencies. Recall that dependencies are at the jar level, but when you export packages some may need to come from the embedded dependencies. If this happens, you will end up with duplicate classes, one set inline in the top level bundle and another in the embedded jar. Of course, you can inline the entire embedded jar, but before you know it this propagates across your entire dependency chain. This is just one of the problems that Roland and others refer to.

Answer 5

Here is an example if you are using the Maven Bundle Plugin .

Note: This plugin automatically imports packages that your dependencies need. This may or may not be a problem for you. Thankfully, you can suppress the packages you don't really need to import (see below).

    <Import-Package>
        <!-- this was imported by one of the dependencies; I don't really need it -->
        !org.apache.jackrabbit.test,
        *
    </Import-Package>
    <Include-Resource>
        lib/concurrent-1.3.4.jar,
        lib/jackrabbit-core-2.6.5.jar,
        lib/jackrabbit-spi-2.6.5.jar,
        lib/jackrabbit-spi-commons-2.6.5.jar,
        lib/lucene-core-3.6.0.jar,
        lib/tika-core-1.3.jar
    </Include-Resource>
    <Bundle-ClassPath>
        .,
        concurrent-1.3.4.jar,
        jackrabbit-core-2.6.5.jar,
        jackrabbit-spi-2.6.5.jar,
        jackrabbit-spi-commons-2.6.5.jar,
        lucene-core-3.6.0.jar,
        tika-core-1.3.jar
    </Bundle-ClassPath>

Answer 6

Can we use OSGI to override the bootstrap classloader jars loaded during runtime, like if we wanted to override JAXP1.4.5 available with Java7 to JAXP1.6, there is -Dendorese feature to override the default API to upgraded API. Can we able to do this thing with the help of OSGI.