使用Maven，DS，SCR在Felix中使用OSGi捆绑包的最低要求是什么？

Question

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

进展似乎如下：

• Direct API access
• ServiceTracker pattern
• Whiteboard pattern
• Declarative Services
• Bnd
• iPojo？ Spring？在这一点上它非常模糊。

有许多不同的库和方法，我需要一种方法来选择合理的方法。我不知道这些技术何时是针对同一问题的重复方法或相互建立的。

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

• Apache Felix
• Apache Sling
• 的Maven

除此之外，我想要一种简单的创建包的方法，而不需要任何重复。

以下是我使用maven和以下插件创建的软件包的截图：maven-bundle-plugin，maven-scr-plugin。

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

1. 的pom.xml 为什么pom.xml包含在jar中？ 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实现以及一种技术结束而另一种技术开始的可靠图景。如果有一个好的图表显示重叠，这将是有帮助的，或者如果有人可以将其缩小到特定的推荐堆栈，所以我可以在整理技术细节时放置一些眼罩，这将是很好的。

Answer 1

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

从你的列表AFAICS中，所有文件都有充分的理由在那里，除了lib下的jar，我认为已经将maven-bundle-plugin包含在内，以嵌入这些依赖项。通常情况下，让您的捆绑包从其他捆绑包中导入这些包，这样它们就可以共享而不是仅仅被捆绑包使用。

如果您正在使用Apache Sling，那么您可以使用Sling codebase中/ bundle下的任何捆绑包作为示例，它们是根据完善的最佳实践构建的。 Sling代码库在构建时使用ServiceTrackers，Whiteboard模式和大量声明性服务以及BND，由Maven插件执行。

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

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