Osgi 为什么不'；bnd工作区模型中的t存储库是否支持可传递依赖项？

根据最新的数据，存储库定义了一组精确的依赖项，而不支持可传递的依赖项，因为它们往往会造成糟糕的OSGi系统

如果这是真的，有人能提供更详细的解释吗（使用具体的用例是非常受欢迎的）？我想这主要与清单中正确的导入包列表有关。如何处理可传递依赖关系？是否有办法提供所有必需的导入

这是否意味着只使用maven的捆绑包开发（使用bnd maven插件或maven捆绑包插件）更容易出错，因为maven支持可传递的依赖关系？在这种情况下，应如何处理可传递依赖关系

---

谢谢大家!

在OSGi包中，创建和组装应用程序是两件截然不同的事情。 当使用maven创建bundle时，当然要使用可传递依赖项。maven bundle插件或bnd maven插件的结果是jar清单中的条目。它们定义了导入或导出包之类的内容。此结果不包含可传递依赖项。这些包可以在工作区模型和maven模型中使用

应用程序集是一个不同的过程。在这里，您构建了一个非常复杂的存储库，它是一个可能要安装的捆绑包列表。在工作区模型中，列出了没有可传递依赖项的每个捆绑包。 在基于maven的应用程序部件中，使用pom的依赖项定义存储库。这里使用了可传递依赖项

可传递依赖关系不总是好的原因是捆绑包的依赖关系通常不是您希望在应用程序中使用的依赖关系。因此，maven模型有可能将有问题的包添加到存储库中。然后，这些依赖关系可能会减慢到要使用的实际捆绑包的解析速度，甚至导致无法工作的解析捆绑包。幸运的是，您可以通过使用常用的maven excludes排除一些可传递的依赖项来解决这个问题

---

根据我个人的经验，传递包对于应用程序组装通常非常有用，因为您不必手动列出所有依赖项。有问题的案例不太容易解决。因此，我不同意不应利用可传递依赖关系。

在OSGi捆绑包创建和应用程序组装中是两件截然不同的事情。 当使用maven创建bundle时，当然要使用可传递依赖项。maven bundle插件或bnd maven插件的结果是jar清单中的条目。它们定义了导入或导出包之类的内容。此结果不包含可传递依赖项。这些包可以在工作区模型和maven模型中使用

应用程序集是一个不同的过程。在这里，您构建了一个非常复杂的存储库，它是一个可能要安装的捆绑包列表。在工作区模型中，列出了没有可传递依赖项的每个捆绑包。 在基于maven的应用程序部件中，使用pom的依赖项定义存储库。这里使用了可传递依赖项

可传递依赖关系不总是好的原因是捆绑包的依赖关系通常不是您希望在应用程序中使用的依赖关系。因此，maven模型有可能将有问题的包添加到存储库中。然后，这些依赖关系可能会减慢到要使用的实际捆绑包的解析速度，甚至导致无法工作的解析捆绑包。幸运的是，您可以通过使用常用的maven excludes排除一些可传递的依赖项来解决这个问题

---

根据我个人的经验，传递包对于应用程序组装通常非常有用，因为您不必手动列出所有依赖项。有问题的案例不太容易解决。因此，我不同意不应利用可传递依赖关系。

主要原因是OSGi是可重用组件系统的规范。如果尝试使用可传递依赖项执行此操作，则会发现在汇编时遇到问题：

• 版本冲突——组件A使用X的版本1，组件B使用X的版本2。这些冲突通常在像Maven这样的过渡系统中逐渐减少，但定时炸弹正潜伏着爆炸
• 环境依赖性–一些组件依赖于Windows，另一些依赖于Linux。很难调和这些分歧
• 版本兼容性——组件通常可以一起工作，但它们的可传递依赖性使其无法工作

为了解决这个问题，OSGi发明了服务模型。服务模型允许组件依赖于API。一旦依赖于API，就不再有可传递依赖项，因为可传递依赖项几乎都与实现依赖项有关。当然，存在对API的依赖，但这已经变得更加模糊，因为API的使用者和提供者都依赖于此。这从根本上改变了依赖模型，但很少有人理解这一点

也就是说，在服务模型中，责任止于服务API。您可以针对API进行编译，并且可以针对API编写许多测试用例。但是，您的组件永远不应该依赖于特定的实现。组件第一次看到实现时应该是在运行时

当然，这在开发的早期阶段会失去一些便利。在一个可传递的模型中，比如Maven，事情应该是开箱即用的，在bnd中，您需要提前考虑您和您的组件的依赖关系。这给Maven用户带来了不便和烦恼，但让组件在非常不同的环境中可重用是一项要求。Maven倾向于将运行时锁定在通常不兼容的配置中，在OSGi中，您不希望运行时有任何不必要的限制来最大限度地提高可重用性