OSGi Maven依赖vs导入包vs嵌入依赖

谁能告诉我之间有什么区别

依赖vs导入包vs嵌入依赖

我真的迷失了示例osgi包的pom文件。

如果使用默认的maven *语句，则解决对其他捆绑软件的依赖性。

为什么需要使用element 将包包括在内？

编辑：我没有任何样品可以放在这里。问题是“如何将捆绑作为依赖项来访问不同捆绑中的其package-> services？”

Maven提供了广泛的依赖模型。一个项目有一个pom，该pom指定了它对其他pom的依赖。这是可传递的，因此具有一个依赖项可以下载一半的Internet。在maven中，您可以指定需要对编译类路径或运行时类路径具有依赖性。

在OSGi中，您应该创建一个可以在不同环境中使用的包。因此，捆绑软件是一个JAR，可使其依赖关系明确。就像Maven一样，您可以让一个捆绑包依赖于另一个捆绑包（Require-Bundle）。但是，需要另一个捆绑包非常脆弱。

它倾向于创建大的依赖图

您很容易遇到需要使用不同版本的相同工件的情况

您需要的方法很多，因为您通常只需要另一个捆绑的一部分

通常，您喜欢使用其他实现

因此，OSGi具有基于功能的本机依赖模型。包装出口是一种能力。在OSGi中，捆绑软件A不依赖于捆绑软件B，而是依赖于软件包 b。（并且包应该表示合同/ API。）任何导出包b的包都将满足包A。此模型具有许多优点，其最大优点是它不具有传递性。这为部署时间提供了极大的灵活性。

在OSGi中，一个主要目标是最大程度地减少依赖关系，并且仅依赖定义良好的API，而不依赖于实现，因此该包易于在许多不同的上下文中使用。

那么如何在Maven中构建它呢？

通常，您可以让bnd分析您的代码。然后，它将创建一个清单，该清单精确表达您的捆绑包所依赖的软件包。

但是，开源中许多代码的结构方式可能使您不仅依赖于API。那么，如何处理这些实现依赖性呢？

使用embed依赖项选项，您可以将maven pom中的所有传递性依赖项（可能很多）拖入其中。我不会使用它。这很快但又很脏，因为您不知道要拖动什么。

通常，我会仔细设计捆绑包。因此，bnd可以指定应包含构建路径中其他工件的哪些软件包。甚至有一种方法可以让bnd计算特定名称空间中需要的内容：

   Conditional-Package: aQute.lib.*

第一次运行这种方法很少会完美，您会在第一次运行时发现错过某些东西，因此需要一些迭代。但是，至少您知道捆绑包中的内容。