OSGI包中Bundle-Classpath的预期用例是什么 [英] What is the intended use case for Bundle-Classpath in OSGI bundles

问题描述

我试图了解OSGI捆绑包中Bundle-Classpath的预期用例.

I am trying to understand the intended use case for Bundle-Classpath in OSGI bundles.

这是我的理解，请帮助我理解这是否正确.

Here is my understanding, please help me understand if this is correct.

比方说，我正在创建一个OSGI捆绑软件，该捆绑软件将部署在其他捆绑软件的生态系统中.我正在处理的捆绑软件需要一些其他捆绑软件，但它们未在此生态系统中加载/导出，并且我无法控制该生态系统导出的内容.在这种情况下，我可以将这些捆绑软件放入某个目录(例如"lib")中，该目录成为我捆绑软件的一部分.还应从Bundle-Classpath引用这些捆绑包，以便可以加载它们.

Let's say I am working on creating an OSGI bundle which will be deployed in an ecosystem of other bundles. The bundle I am working on needs some other bundles, but they are not loaded/exported in this ecosystem, and I do not have control on what the ecosystem exports. In such a scenario, I can put these bundles inside some directory (say 'lib') which becomes part of my bundle. These bundles should also be referenced from the Bundle-Classpath, so they can be loaded.

• 这是Bundle-Classpath的正确用例吗?
• 这些额外的捆绑软件是否还会加载到OSGI容器中，并且它们导出的软件包是否可用于其他捆绑软件?

推荐答案

Bundle-ClassPath旨在将依赖项包含在我们的捆绑软件中，以便我们的捆绑软件可以独立部署.

Bundle-ClassPath is intended for including dependencies in our bundle, so that our bundle can be deployed standalone.

让我们举个例子.假设我包中的代码使用一个库，例如Google Guava.我有两种包装包装的选择:

Let's take an example. Suppose the code in my bundle uses a library, e.g. Google Guava. I have two choices for packaging my bundle:

1. 仅在其中包含我自己的代码的情况下创建我的捆绑软件.现在，该捆绑包将具有Import-Package语句，该声明声明对Guava的依赖关系，并且想要将我的捆绑包部署到其应用程序中的任何人也将必须部署Guava.

1. Simply create my bundle with only my own code inside it. The bundle will now have the Import-Package statements that declare a dependency on Guava, and anybody who wants to deploy my bundle into his application will also have to deploy Guava.

或者，我可以在包中包含一个番石榴副本，并从我的Bundle-ClassPath中引用它.部署我的捆绑包的任何人都可以部署 just 我的捆绑包，而无需担心从何处获得番石榴.实际上，捆绑包中存在的番石榴是一个实现细节，部署者甚至不需要知道我正在使用它.

Alternatively I can include a copy of Guava inside my bundle and reference it from my Bundle-ClassPath. Whoever deploys my bundle can deploy just my bundle, and doesn't need to worry about where to get Guava from. In fact, the existence of Guava inside my bundle is an implementation detail, and the deployer doesn't even need to know that I am using it.

这两个选项之间的选择是一个权衡.选项2的优点是我的捆绑包是独立的，因此更易于部署-它所需要的一切都在其中.另一方面，我的捆绑包比需要的大得多，如果很多其他捆绑包也嵌入了自己的番石榴副本，这可能会成为问题.

The choice between these two options is a trade-off. Option 2 has the advantage that my bundle is easier to deploy because it is standalone -- everything it needs is right there inside it. On the other hand my bundle is much bigger than it needs to be, which could become a problem if lots of other bundles also embed their own copy of Guava.

选项2的一个更严重的问题是该库的所有依赖项现在也都变成了 my 依赖项.实际上，Guava是Java库中很少有的例子，它没有自己的依赖关系...但是许多其他Java库拖累了巨大的传递依赖树.如果您将这种方法与Hibernate一起使用，那么您自己的捆绑软件也将具有较大的依赖关系集.这变得非常丑陋，很快.

A more severe problem with option 2 is that all of the dependencies of the library now become my dependencies as well. Actually Guava is a rare example of a Java library with no dependencies of its own... but many other Java libraries drag in a huge tree of transitive dependencies. If you use this approach with, say, Hibernate then your own bundle will also have that large dependency set. This gets very ugly, very quickly.

因此，您应该小心不要过度使用Bundle-ClassPath/Embed-Dependency.您应该仅在以下情况下考虑使用它:(a)依赖性小，并且没有传递性依赖性，并且(b)捆绑软件将库用作内部实现细节，即它不是公共API的一部分.

So, you should be cautious not to overuse Bundle-ClassPath/Embed-Dependency. You should only consider using it if the dependency is (a) small, and with no transitive dependencies, and (b) your bundle uses the library as an internal implementation detail, i.e. it is not part of your public API.

更新

我忘了回答关于出口的第二个问题.答案是否定的，您放置在Bundle-ClassPath上的任何捆绑包"的出口都不会成为您自己捆绑包的出口.实际上，我们放在Bundle-ClassPath上的JAR根本不被视为捆绑包，它们只是JAR.

I forgot to answer your second question about the exports. The answer is NO, the exports of any "bundles" you put on your Bundle-ClassPath will NOT become exports of your own bundle. In fact the JARs we put on Bundle-ClassPath are not treated as bundles at all, they are just JARs.

您可以选择导出来自Bundle-ClassPath上JAR内的软件包，但是必须在您自己的捆绑软件的MANIFEST.MF中执行此操作.

You can choose to export packages that come from within the JARs on your Bundle-ClassPath but you have to do this in the MANIFEST.MF of your own bundle.

这篇关于OSGI包中Bundle-Classpath的预期用例是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！