是否有一种方法可以将OSGI捆绑包用作maven依赖项，而不必将其所有包都放到它甚至不导出的类路径中？
问题的背景：我们刚刚将org.apache.sling.xss捆绑包作为maven依赖项添加到我们的项目中。如您所见，in the pom.xml仅导出包org.apache.sling.xss，但将各种依赖项直接嵌入jar中，作为Private-Package。虽然OSGI从其他捆绑包中隐藏了这些东西，但maven却没有。因此我们发生了冲突：org.apache.sling.xss嵌入例如1.7.0版commons-beanutils，与我们一直在使用的较新版本的commons-beanutils不兼容，因此我们现在遇到编译错误。
从我们的角度来看，还是从org.apache.sling.xss软件包的维护者的角度来看，有什么好的解决方案？理想情况下，如果使用该捆绑包，则只会将导出的org.apache.sling.xss包放入类路径中。因此，如果org.apache.sling.xss提供一个单独的仅包含该类的API jar，也许是一个好的解决方案？有标准的方法可以做到这一点，还是有其他解决方案？我们可以以某种方式告诉Maven仅将那个包包括在类路径中吗？ （我知道maven具有dependency exclusion，但这在这里无济于事，因为有问题的东西不是sling.xss的可传递依赖项，而是实际上包含在org.apache.sling.xss jar中。）
答案 0 :(得分：2)
不幸的是，没有使用maven处理此类捆绑包的好方法。
推荐的方法是将捆绑包分为仅定义API的API捆绑包和导入API并导入或嵌入所有实施依赖项的实现捆绑包。
这样，使用者将仅具有对该API的maven依赖，而根本不会发生此问题。
您能为xss吊索提供API捆绑包吗？
答案 1 :(得分：0)
您可以在构建系统中包括执行OSGi解析的步骤，例如使用bnd-export-maven-plugin。
如果您编写的代码依赖于另一个捆绑软件的未导出包，则整个构建 将会失败。这是因为bnd会自动为您在捆绑软件中使用的软件包添加一个Import-Package，但是resolve步骤将无法在另一个捆绑软件中找到相应的Export-Package。
当然这不是理想的。您仍然可以在IDE中编写代码，并使用maven-compiler-plugin对其进行编译。但是您至少要在运行时之前找到问题所在。