Avoid duplicating OSGi imports in maven dependancies?

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 ecli开发者_高级运维pse 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?

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).

You cannot develop bundles like regular Java projects with Maven and eclipse. You basically have 2 options.

• Apache Felix Bundle Plugin: Basically you develop the project as a regular Java project and use Maven as you normally would. This plugin will be used to add all the OSGi specifics to the jar manifest at deployment time to OSGi enable it. The disadvantage of this aproach is that you are using a Java project in your workspace instead of a bundle, which makes running your project in the OSGi container a little extra work since Eclipse doesn't recognize it as a plugin project. Thus you have to add the jar from the Maven build as part of the target platform manually.
• Tycho: This is another Maven plugin that attempts to actually bring theses two environments together and does a pretty good job of it. In this scenario, you actually create an Eclipse bundle/plugin project, which obviously makes for seamless integration in Eclipse. The pom then marks the project as being an eclipse-plugin type, which effectively makes Maven resolve the project dependencies (defined in the manifest) via the target platform instead of Maven itself.

I would take the Tycho approach as it gives a much more integrated approach with Eclipse.

Having the whole jar as a dependency shouldn't be a problem, that's how you have to do it with Maven anyway.