在与maven一起使用OSGI包时如何隐藏嵌入式依赖项？

Question

Is there a way to use an OSGI bundle as a maven dependency without getting all the packages from it into the classpath that it doesn't even export?

Background of the question: We just added the org.apache.sling.xss bundle as a maven dependency into our project. As you can see in the pom.xml , it just exports the package org.apache.sling.xss but embeds various dependencies directly into it's jar as Private-Package . While OSGI hides this stuff from other bundles, maven does not. So we get collisions: org.apache.sling.xss embeds eg version 1.7.0 of commons-beanutils, which is incompatible with the newer version of commons-beanutils we have been using, so that we now get compile errors.

Is there any good solution to this - both from our perspective, as from the perspective of the maintainers of the org.apache.sling.xss bundle? Ideally, you'd get only the exported org.apache.sling.xss package into the classpath if you use that bundle. So maybe a good solution would be if org.apache.sling.xss provided a separate API jar, containing only that class? Is there a standard way to do this, or another solution? Can we somehow tell maven just to include only that package into the classpath? (I know maven has dependency exclusion , but that doesn't help here, since the problematic stuff is not a transitive dependency of sling.xss, but actually included into the org.apache.sling.xss jar.)

Answer 1

Unfortunately there is no good way to handle such bundles with maven.

The recommended way is to split the bundle into an API bundle that just defines the API and an implementation bundle that imports the API and imports or embeds all implementation dependencies.

This way consumers will only have a maven dependency to the API and the problem does not occur at all.

Can you open an jira issue for sling xss to provide an API bundle?

Answer 2

You could include in your build system a step that performs OSGi resolution, for example using the bnd-export-maven-plugin .

In this way the build as a whole will fail if you write code that depends on a non-exported package of another bundle. This is because bnd will automatically add an Import-Package for the package that you used in your bundle, but the resolve step will be unable to find a corresponding Export-Package in the other bundle.

Of course this is not ideal. You will still be able to write the code in your IDE and compile it with the maven-compiler-plugin . But you at least find out about the problem before you hit the runtime.