【问题标题】:Maven OSGi bundlingMaven OSGi 捆绑
【发布时间】:2014-11-07 07:51:07
【问题描述】:

我正在使用 maven felix 插件来创建 OSGi 包,但是假设您在 project1 和 project2 中存在一个包“com.example”。此外,project2 对 project1 有依赖关系。

如果您在 project2 中导出包,它将具有 project2 的代码来自 project1 的代码。这 - 对我来说 - 真的很奇怪。我能想到他们启用这种行为的唯一原因是因为 OSGi 以某种方式需要它? (我已经看过http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html,但似乎找不到关闭它的方法)

如果两个 jar(A 和 B)导出相同的包但其中的类不同,并且第三个 jar(C)依赖于该包,我会假设 C 在运行时可以同时看到 A 和 B。或者 OSGi 是否需要每个 jar 不同的包?

如果 OSGi 没有强制执行此操作,我该如何关闭此“功能”?

如果 OSGi 强制要求,那么...为什么?

更新

Christian 提供的答案清除了不同 jar 中不同包的 OSGi 要求。但是我仍然对 felix 有问题,我有一个“api”jar,其中包含:

  • com.example.api:实际接口
  • com.example:工厂类,实用程序类,...

还有一个实现包:

  • com.example.impl

现在,当我使用 felix 构建实现包并导出“com.example.impl”时,它确实会包含“com.example.impl”中的所有内容,但由于某种原因,它还包含“com.example.impl”中的所有类。示例”(不是 .api 中的那些)。我尝试过的任何设置组合都不会因为某种原因阻止 felix 添加“基础”包...

所以基本上在“impl”项目的结果 jar 中,我实际上有 api 包中的 com.example.MyFactory 类。我怎样才能阻止这个?

【问题讨论】:

    标签: java osgi


    【解决方案1】:

    OSGi 并不要求您在两个项目中使用相同的包。事实上,您应该避免在两个包含不同内容的包中使用相同的包/版本组合。

    在 OSGi 中,当捆绑包从已安装到已解决时,就会发生布线。在该步骤中,框架将每个 Import-Package 语句与匹配名称和版本范围的导出包进行匹配。在 OSGi 中,即使多个包导出同一个包,每个包也只会连接一个包。这与标准 java 不同,在标准 java 中,您将混合所有 jar 中的类,这些 jar 具有包,这可能会产生非常不可预测的结果。

    在 OSGi 中有一种模式,您可以在多个包中拥有相同的包。它经常用于 OSGi 的官方 API。在那里,当您实现 API 时,您还包括 API 包,并拥有 API 包的 Import-Package 和 Export-Package 语句。这允许安装实现包而不需要额外的 API 包。即使有多个包包含 API,这也能很好地工作,因为框架会选择其中一个 API 包并将所有其他包连接到同一个包。所以他们都看到相同的类集并且没有冲突。

    您也可以为自己的应用程序执行此操作,但更常见的做法是将 API 包放在一个包中,而所有其他包只需导入它。

    您可以在 apache felix OSGi Frequently Asked Questions 找到一些信息


    回答您更新的问题。我猜你只导出 com.example.api 包。所以 maven bundle 插件知道它可以使用 Import-Package 语句来引用这个包。由于 com.example 未导出,因此插件知道 Import-Package 不起作用。所以它嵌入了类。

    所以你应该带走的是你需要导出其他包需要的所有包。顺便提一句。您通常不会在 OSGi 中导出 impl 包。而是将 impl 隐藏在服务后面。服务接口放在API中。然后 impl 包实现接口并将 impl 导出为 OSGi 服务。所以其他 bundle 可以通过其接口绑定服务,整个 impl 可以保持私有。

    【讨论】:

    • 感谢您的反馈,它已经清晰了很多,但我添加了一个更具体的用例,这仍然让我对原始问题感到沮丧。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-01-07
    • 2011-12-31
    • 1970-01-01
    • 2014-12-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多