maven - OSGi Maven 依赖项 vs import-packge vs embed-dependency

Question

谁能告诉我两者有什么区别

dependencies vs import-packge vs embed-dependency

看着示例 osgi 包的 pom 文件，我真的很迷茫。

如果默认 maven <import-package>*</import-package>语句解决对其他包的依赖。

为什么需要使用 <dependency> 包含捆绑包元素 ？

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

Answer 1

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

在 OSGi 中，您应该创建一个可以在不同环境中使用的包。出于这个原因，bundle 是一个 JAR，它明确了它的依赖关系。就像Maven一样，你可以让一个bundle依赖另一个bundle(Require-Bundle)。然而，事实证明需要另一个捆绑包非常脆弱。

它倾向于创建大型依赖图

您很容易陷入需要在不同版本中使用相同 Artifact 的情况

您需要很多，因为您通常只需要另一个包的一部分

通常你喜欢使用不同的实现

因此，OSGi 具有基于功能的 native 依赖模型。包导出是一种能力。在 OSGi 中，Bundle A 不依赖于 Bundle B，但它依赖于包 b。 (并且包应该代表一个合约/API。)任何导出包 b 的包都将满足包 A。这个模型有很多优点，它最大的优点是它不是可传递的。这为部署时间提供了极大的灵活性。

在 OSGi 中，一个关键目标是最小化依赖关系，只依赖定义良好的 API，从不实现，因此 bundle 在许多不同的上下文中都很容易使用。

那么你如何在 maven 中构建它呢？

通常，您让 bnd 分析您的代码。然后它会创建一个 list ，精确地表达你的包所依赖的包。

然而，许多开源代码的结构方式很可能不仅仅依赖于 API。那么如何处理这些实现依赖呢？

使用嵌入依赖项选项，您从 maven pom 中拖入所有传递依赖项(并且可能很多)被拖入。我不会使用它。它很快但也很脏，因为你不知道你拖进去的是什么。

一般来说，我会仔细设计捆绑包。因此，bnd 可以指定应包含构建路径上其他 Artifact 的哪些包。甚至有一种方法可以让 bnd 计算特定命名空间所需的内容:

   Conditional-Package: aQute.lib.*

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