2

在 OSGi 中连接组件的过程似乎随着时间的推移而发展。

进展似乎如下：

有很多不同的库和方法，我需要一种方法来筛选出合理方法的选项。我不知道这些技术何时是解决同一问题的重复方法或相互构建的方法。

我知道我将使用以下内容：

  • 阿帕奇费利克斯
  • 阿帕奇吊索
  • 马文

除此之外，我想要一种直接的技术来创建包，而无需任何重复。

这是我使用 maven 和以下插件创建的包的屏幕截图：maven-bundle-plugin、maven-scr-plugin。

OSGi 包

我注意到很多冗余，不确定什么是必要的。

  1. pom.xml 为什么jar中包含pom.xml？OSGi 是否需要从 OSGi Bundle Repository (OBR) 中提取依赖项？

  2. MANIFEST.MF 这也列出了依赖项并引用了 serviceComponents.xml Service-Component: OSGI-INF/serviceComponents.xml

  3. serviceComponents.xml 似乎是对带有 SCR 注释的 XML 表达式的清单的扩展。在这一点上，Java 类中的 SCR 注释是无关紧要的，还是 OSGi 会使用这个 XML 来查找带有注释的类？我猜如果我使用 iPojo 这个 XML 会被 iPojo XML 取代？

  4. scrinfo.xml 这是 serviceComponents.xml 的副本，它只添加private="false"到每个节点。

  5. metatype.xml 这看起来像其他生成的 XML，但没有使用 SCR 命名空间。

  6. 我猜这些是我的包的私有依赖项，不会暴露给系统的其余部分。

我不喜欢这是一个曲折的问题，但我似乎无法找到关于 OSGi 的 Apache-Felix 实现正在寻找什么以及一种技术结束而另一种技术开始的可靠图片。如果某个地方有一个很好的图表来显示重叠，那将很有帮助，或者如果有人可以将其缩小到特定的推荐堆栈，这样我就可以在整理技术细节时戴上一些眼罩，那就太好了。

4

1 回答 1

3

除非你有正当的理由担心一些额外的字节，否则我不会太担心 Maven 插件在你的 bundle jar 中放了什么。

从您的 AFAICS 列表中，所有文件都有充分的理由存在，除了 lib 下的 jars，我假设 maven-bundle-plugin 已包含这些 jars 以嵌入这些依赖项。通常最好让你的包从其他包中导入这些包，这样它们就可以被共享而不是只被你的包使用。

如果您正在使用 Apache Sling，您几乎可以将Sling 代码库中 /bundles 下的任何捆绑包作为示例，它们是根据公认的最佳实践构建的。Sling 代码库确实使用了 ServiceTrackers、白板模式和许多声明式服务，以及在构建时由 Maven 插件执行的 BND。

我自己没有使用过 iPojo，我认为它可以与 Sling 配合使用，但我们还没有看到 Sling 本身需要它。

我不喜欢在 OSGi 应用程序中使用 Spring，似乎有些人成功地做到了这一点，但 IMO 是一个额外的层，与普通的声明式服务相比并没有带来太多价值。

于 2013-11-07T19:37:14.227 回答