Avoid duplicating OSGi imports in maven dependancies?

Question

Currently when I am writting a bundle in that depends on a package, I have to "import" or "depend" on a whole other bundle in Maven that contains that package.

This seems like it is counter-productive to what OSGi gives me.

For example let's say I have two bundles: BundleAPI and BundleImpl.

BundleAPI provides the API interfaces:

// BundleAPI's manifest
export-package: com.service.api

BundleImpl provides the implementation:

//BundleImpl's manifest
import-package com.service.api

However, when I am coding BundleImpl in Eclipse, I am forced to "depend" in maven POM on BundleAPI itself - so that eclipse does not complain.

//BundleImpl's POM
<dependency>
    <groupId>com.service</groupId>
    <artifactId>com.service.api</artifactId>
    [...]
</dependency>

So - on one hand, I am depending only on the package com.service.api, while on the other - I need to have the whole bundle - BundleAPI.

Is there a way to make maven or eclipse smart enough to just find the packages somewhere, instead of whole bundles?

I am very much confused as to how this works - any type of clarity here would be great. Maybe I am missing something fundamentally simple?

Answer 1

The key is to distinguish between build-time dependencies and runtime dependencies.

At build time you have to depend on a whole artifact, i.e. a JAR file or bundle. That's pretty much unavoidable because of the way Java compilers work. However at runtime you depend only on the packages you use in your bundle, and this is how OSGi manages runtime substitution. This is the Import-Package statement in your final bundle.

Of course as a developer you don't want to list two parallel sets of dependencies, that would be crazy. Fortunately maven-bundle-plugin is based on a tool called bnd that calculates the Import-Package statement for you based on analysing your code and discovering the actual packages used. Other tools such as bndtools (an Eclipse-based IDE for OSGi development) also use bnd in this way. Incidentally bnd is much more reliable and accurate than any human at doing this job!

So, you define only the module-level dependencies that you need at build time, and the tool generates the runtime package-level dependencies.

I would recommend against using Tycho because it forces you to use Eclipse PDE, which in turn forces you to manually manage imported packages (for the sake of full disclosure, I am the author of bndtools which competes against PDE).