捆绑 OSGi 依赖库的标准方法是什么？
我有一个项目引用了许多开源库，有些是新的，有些不是那么新。也就是说，它们都很稳定，我希望坚持使用我选择的版本，直到我有时间迁移到较新的版本（我昨天测试了 hsqldb 2.0，它包含许多 api 更改）。
我希望嵌入的库之一是 Jasper Reports，但正如你们肯定知道的那样，它附带了大量的支持 jar 文件，而我只需要山的一个子集（已知），因此我计划自定义捆绑所有我的依赖库。
那么：
是否每个人都为他们正在使用的开源库定制自己的 OSGi 捆绑包，或者是否有公共库的 OSGi 版本的主源？
此外，我认为对于我的每个包来说，只需将其依赖的 jar 嵌入到包本身中会简单得多。这可能吗？如果我选择将第 3 方 foc 库嵌入到一个包中，我假设我需要生成 2 个 jar 文件，其中一个没有嵌入库（用于通过标准类加载器通过类路径加载的库），以及一个 osgi 版本，其中包括嵌入式库，因此我应该选择像这样的包名称 <
>-< >-osgi-.1.0.0.jar ？ 如果我无法嵌入开源库并选择自定义捆绑开源库（通过 bnd），我是否应该选择唯一的捆绑包名称以避免与可能的官方捆绑包发生冲突？例如 <
>-<<3rdpartylibname>>-<<3rdpartylibversion>>.jar ? 我的非 OSGi 启用项目当前通过 Service.providers(...) 扫描我的各种插件 jar 中的 META-INF 文件夹来扫描自定义插件。如果我使用 OSGi，这个机制仍然有效吗？
I have a project that references a number of open source libraries, some new, some not so new. That said, they are all stable and I wish to stick with my chosen versions until I have time to migrate to the newer versions (I tested hsqldb 2.0 yesterday and it contains many api changes).
One of the libraries I have wish to embed is Jasper Reports, but as you all surely know, it comes with a mountain of supporting jar files and I have only need a subset of the mountain (known) therefore I am planning to custom bundle all of my dependant libraries.
So:
Does everyone custom-make their own OSGi bundles for open-source libraries they are using or is there a master source of OSGi versions of common libraries?
Also, I was thinking that it would be far simpler for each of my bundles simply to embed their dependent jars within the bundle itself. Is this possible? If I choose to embed the 3rd party foc libraries within a bundle, I assume I will need to produce 2 jar files, one without the embedded libraries (for libraries to be loaded via the classpath via standard classloader), and one osgi version that includes the embedded libraryy, therefore should I choose a bundle name like this <<myprojectname>>-<<subproject>>-osgi-.1.0.0.jar ?
If I cannot embed the open source libraries and choose to custom bundle the open source libraries (via bnd), should I choose a unique bundle name to avoid conflict with a possible official bundle? e.g. <<myprojectname>>-<<3rdpartylibname>>-<<3rdpartylibversion>>.jar ?
My non-OSGi enabled project currently scans for custom plugins via scanning the META-INF folders in my various plugin jars via Service.providers(...). If I go OSGi, will this mechanism still work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我宁愿不嵌入依赖罐子（是的，这是可能的）。它会导致两个问题，
1）没有重用此代码。许多捆绑包可能只是做同样的事情（嵌入相同的 jar），最终您会多次安装相同的 jar。您可以争辩说您的捆绑包也可以导出嵌入式 jar 的接口，但这会变得丑陋，因为公开该代码不应该是您的捆绑包的责任。它还使得公开多个版本的库或同一版本的多个提供者变得更加容易。
2) 这是 Eclipse 特有的 - 嵌入式 jar 在开发环境中无法正确解析（在运行时仍然有效）。我的捆绑包可能依赖于目标平台中的捆绑包，并且它将无法解析嵌入式 jar 中的元素，必须将它们导入工作区才能工作。
我发现大多数开源 jar 已经由 Spring 的好心人捆绑。还有其他可用的存储库，但不幸的是我丢失了它们的链接。
I prefer to not embed the dependent jars (yes it is possible). It causes two problems,
1) There is no reuse of this code. Many bundles may simply do the same thing (embed the same jar) and you end up with the same jar installed many times. You can argue that your bundle can export the interfaces for the embedded jar as well, but this gets ugly since it should not be your bundles responsibility to expose that code. It also makes it easier to have multiple versions of the library exposed, or multiple providers of the same version.
2) This is Eclipse specific - The embedded jars don't resolve properly in the development environment (still works at runtime). My bundle may depend on a bundle in my target platform, and it will fail to resolve elements in the embedded jars, they have to be imported into the workspace to work.
I have found that most open source jars have already been kindly bundled by the nice folks at Spring. There are other repos available as well, but unfortunately I lost my links to them.
也许您正在寻找类似 Maven 的东西？但不确定 OSGi 会如何工作。您可以在此处找到有关 Jasper Reports with Maven 的一些信息：
http://mvnrepository.com/artifact/jasperreports/jasperreports
Perhaps you are looking for something like Maven? Not sure how that would work with OSGi though. You can find a little info on Jasper Reports with Maven here:
http://mvnrepository.com/artifact/jasperreports/jasperreports
Eclipse Orbit 项目还从许多常用的第三方 jar 中制作了捆绑包。
http://www.eclipse.org/orbit/
The Eclipse Orbit project has also made bundles from many commonly used third party jars.
http://www.eclipse.org/orbit/
要具体说明您提出的问题。
每个人都不会自己做。请参阅我之前的回答，获取 Eclipse 将第三方库打包为捆绑包的链接。如果你找不到已经打包的版本，你就必须自己制作。
将二进制依赖项包装在自己的包中比将 jar 作为二进制文件包含到代码包中更好。选择您想要的任何包名称，重要的是包的导入和导出。将包名称与项目名称命名空间将确保不会发生冲突。
访问包存储区域进行扫描并非不可能，但它往往需要 OSGi 运行时特定信息，以了解如何/在何处提取包。所以这是可能的，但并不容易。
To be specific about the questions you asked.
Everyone doesn't make their own. See my previous answer for a link to the Eclipse packaging of third party libraries as bundles. If you can't find and already packaged version, you'll have to make your own.
It is better to wrap binary dependencies in their own bundle than to include the jar as a binary into your code bundle. Pick whatever bundle name you want, its the package imports and exports that matter. Namespacing the bundle name with your project name will make sure you don't hit collisions.
Getting access to the bundle storage area for scanning isn't impossible, but it tends to require OSGi runtime specific information on how/where the bundles get extracted. So it's possible, but not easy.
spring 已经创建了大多数开源库的 osgi 捆绑包，我在那里看到了 jasper 报告。查看他们的捆绑存储库@ http://www.springsource.com/repository/app/bundle< /a>
spring has created osgi bundles of most of the open source libraries and i see jasper reports in there. check out their bundle repository @ http://www.springsource.com/repository/app/bundle
我们一直在 OSGI 中使用 Maven ，我们在其 pom.xml 中声明了包依赖项，而您没有不用再担心他们了。
we have been using Maven with OSGI, we declare the bundle dependencies in its pom.xml and you don't have to worry about them anymore.