Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Problems with maven built OSGi including dependencies

I'm currently starting with OSGi, iPOJO and iPOJO Annotations and trying to build a simple component to be deployed in Felix. Unfortunately, I'm stumbling over various problems which take me hours to solve or which I cannot even solve after wasting hours, like the following:

I want to use an existing library in my OSGi bundle which we build using Maven. The library is currently not "OSGI-ified" and we are not planning to do so in the medium term. Because of that, I want to include this library and all of its dependencies in the bundle, using …:

<Embed-Dependency>*</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>

What I have now, is the following pom.xml file for the OSGi component:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>foo</groupId>
    <artifactId>samplecomponent</artifactId>
    <packaging>bundle</packaging>
    <version>0.0.1-SNAPSHOT</version>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <compilerArgument>-Xlint:all</compilerArgument>
                    <showWarnings>true</showWarnings>
                    <source>1.6</source>
                    <target>1.6</target>
                    <compilerArguments>
                        <encoding>UTF-8</encoding>
                    </compilerArguments>
                    <showDeprecation>true</showDeprecation>
                    <verbose>true</verbose>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <version>2.3.6</version>
                <configuration>
                    <instructions>
                        <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                        <Embed-Dependency>*</Embed-Dependency>
                        <Embed-Transitive>true</Embed-Transitive>
                        <Embed-Directory>lib</Embed-Directory>
                        <Export-Package>*</Export-Package>
                        <_exportcontents>*</_exportcontents>
                    </instructions>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-ipojo-plugin</artifactId>
                <version>1.6.0</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>ipojo-bundle</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
    <dependencies>
        <dependency>
            <groupId>org.apache.felix</groupId>
            <artifactId>org.apache.felix.ipojo.annotations</artifactId>
            <version>1.8.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>foo</groupId>
            <artifactId>mylibrary</artifactId>
            <version>1.2.3</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>
</project>

The bundle jar file is built without any problems, but when deploying and starting the bundle on Apache Felix, I get the following error:

g! install file:/…/samplecomponent-0.0.1-SNAPSHOT.jar 
Bundle ID: 8
g! start 8
org.osgi.framework.BundleException: Unresolved constraint in bundle samplecomponent [8]: Unable to resolve 8.0: missing requirement [8.0] osgi.wiring.package; (osgi.wiring.package=com.sun.jdmk.comm)

I have set the log level to the highest verbosity, no more information unfortunately. When I remove mylibrary, the bundle is started without problems.

Any suggestions appreciated!

like image 269
qqilihq Avatar asked Feb 15 '12 11:02

qqilihq


2 Answers

Apparently, the library uses com.sun.jdmk.comm, which is not exposed from the framework bundle. You can check this question if you really need it, or exclude it from the imports by putting in an additional instruction,

<Import-Package>!com.sun.jdmk.comm, *</Import-Package>
like image 82
Angelo van der Sijpt Avatar answered Oct 05 '22 23:10

Angelo van der Sijpt


If you end up with a huge exclude list, you should probably take that as an indication that something isn't right with your build process and the bundle.

If it was me, the first thing I'd do is crack open your bundle and have a look at what classes it includes, and what packages it exports. I suspect you've got a pretty massive bundle, which means your bundle's dependencies are going to be pretty extensive. This means you lose a lot of the modularity benefits of OSGi, and it can cause a lot of practical problems too.

Any time you declare a package to be optional, you're saying 'I'm happy to accept ClassDefNotFoundExceptions for classes in this package.' For your code you can probably know if a package genuinely is optional, but it's pretty tricky to guess which packages used by a third party are optional. This, of course, is why pre-bundleised jars are more convenient, but I realise this isn't much help to you. :)

What you're doing by embedding the third party library is bundleising it, but in a way which isn't so reusable. (The other difference is that it will share a classloader with the embedding bundle, which could make things work a lot better if the third party library tries to load your classed by reflection, for example.) Since you're having problems with the dependencies, I'd be inclined to take the hit of adding a build step which wraps the third party jar, so that you can clearly see what classes and dependencies relate to your code, and which to this extra jar.

The other thing I'd look at is your export package=* clause. This will export every package on your classpath, which means all those packages get built into your jar. And you get all their package imports, too. Your poor bundle becomes a whole application, rather than the lean OSGi module you were hoping for. You should restrict your exports to the bare minimum (you want to keep your innards private, and you definitely don't want to be sharing everyone else's innards).

--

Enterprise OSGi in Action: http://www.manning.com/cummins

like image 38
Holly Cummins Avatar answered Oct 06 '22 00:10

Holly Cummins