我有一个关于OSGI Bundles和“普通”maven jar依赖关系的问题。
以下情形：
多模块maven项目：A
使用模块A.X，A.M：
A.X是OSGI Bundle
A.M是正常的java应用程序，它启动OSGI框架并加载包A.X
在项目顶层pom（A.pom）中，我定义了对commons-logging-1.1.1的依赖 然后我在我的OSGI Bundle A.X中使用commons-logging。 maven-bundle-plugin为A.X生成清单，其中包含导入'commons-logging'的导入条目。
当我启动A.M并在控制台上打印出所有加载的jar（使用getSystemClassLoader ...）时，会列出../../../commons-logging-1.1.1.jar。 由于来自顶级pom的maven依赖性。
现在我尝试安装我的OSGI包A.X并获得“bundle ..... commons-logging”中的“未解决的约束”异常。
为什么在安装捆绑包时，使用已在内存中的commons-logging lib（在A.M中）来解析commons-logging依赖（来自A.X）？
我很感激任何帮助!!!!
答案 0 :(得分：1)
使用getSystemClassLoader打印出加载的jar并不一定能告诉你OSGi可用的内容 - 记住OSGi有自己的类加载机制。
据我所知，commons-logging必须是来自其他捆绑包的exported，以便OSGi可以将其连接到您的AX组件 - 可能有公共日志的捆绑或功能，您可以轻松添加为依赖。
我不确定你正在使用哪个OSGi容器（我使用Fuse），但是应该有一些方法来查看你正在使用的bundle的导入和导出。由于A.X导入commons-logging，另一个bundle需要导出它（具有适当的版本）。
在融合世界中，向系统包添加依赖关系就像将其添加到 features.xml 文件一样简单。但由于我不知道你正在使用哪个容器，我不知道你怎么能这样做。
这有帮助吗？
答案 1 :(得分：0)
那是因为你的一个OSGI包正在使用commons日志中的东西，这不是osgi中的导出包。因此，您要么找到捆绑的commons-logging版本并导出您尝试使用的包，要么将jar添加到用户包的bundle-classpath（还有其他更脏的选项）。第一种选择比第二种选择要好得多，因为它是模块化的;即你可以在不改变任何其他捆绑的情况下更新公共记录。
就像已经提到的那样，它在app类路径中的事实是无关紧要的