Question

In OSGi, the resolution process of defined dependencies, i.e. Package imports and exports, is pretty strict when using version numbers and version ranges. If for some package import of version 1.2.3 no corresponding export with a range containing 1.2.3 is found, the bundle cannot be resolved or started. This is good.

However, this does not seem to apply to the core package org.osgi.framework. Current versions of both Equinox (3.8.0) and Apache Felix (4.0.3) define org.osgi.framework,version=1.7.0 as one of the exported packages. But a bundle requiring a specific lower version of this package, e.g. Import-Package: org.osgi.framework;version=1.3, is still resolved this to this newer version. I would expect the bundle not to get resolved.

How can this behavior be explained? Is this a misbehavior of the OSGi implementations? An I missing an exception when resolving core OSGi packages? Or is Karaf getting in the way here (I tested this with Apache Karaf, see below)

I know that I'd rather not declare the version explicitly and that the version would result in a range which were perfectly resolvable. However there are bundles not under my control defining such imports (namely: iPOJO, see below).


Some setup details: I tested this in Karaf 2.3.2 and 2.3.3, with Equinox or Felix enabled respectively. You can find a demo bundle I used for the tests over at github, which can be built as is and will show the failure when deployed to a fresh Karaf container. The reason I found this out is because the core iPOJO bundle defines such explicit versions rather than ranges. I added this to a Karaf feature descriptor and tried to verify the feature export/import integrity using the Karaf Features Maven Plugin, which fails.

Was it helpful?

Solution

In OSGi, an import of version=1.3 is equivalent to version="[1.3,∞)". See section 3.2.6 "Version Ranges." This is for historical reasons.

You should always use complete version ranges in your import package statements.

OTHER TIPS

No, package imports in OSGi are NOT, repeat NOT, treated differently. OSGi never makes exceptions for its own services or code, it is completely symmetric.

As BJ stated in his answer, an import for version X is actually an import for X and anything higher.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top