Karaf 和 OBR 中的功能有什么区别
我正在研究部署和更新 OSGI（特别是 Karaf）应用程序的方法。似乎有几种选择。一是使用 OSGi Bundle Repository (OBR)，二是使用 Karaf 中的功能，三是使用 卡拉夫洞穴。
我不太确定这些选项有何不同。他们似乎都在做同样的事情。它们只是相同功能的不同实现吗？有人可以解释一下差异或提供一些建议吗？
I am looking into ways to deploy and update an OSGI (Karaf, specifically) application. It seems that there are several options. One is to use The OSGi Bundle Repository (OBR), another is to use Features in Karaf, and the third is to use Karaf Cave.
I'm not really sure how these options are really different. They all seem to be doing the same things. Are they just different implementations of the same functionality? Could someone please explain the differences or provide some recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Karaf 功能和 OBR 是解决（某种程度上）相同问题的不同方法。两者都允许您将 OSGi 捆绑包安装到 OSGi 框架中，但它们决定安装哪些捆绑包的方式不同。
对于 Karaf 功能，您可以提供一个文件（例如 feature.xml），其中明确列出了该功能的所有捆绑包的 URL。它们可以存在于文件系统、maven 存储库或可以通过 URL 描述的任何其他位置。
另一方面，OBR 根据需求和功能确定要制定的捆绑包。它将计算出您作为起点安装的任何内容的传递依赖项，并确保它们全部安装。通常，您会配置一个或多个支持 OBR 格式的外部存储库，然后运行时中的 OBR 解析器将从这些存储库提供捆绑包。因此，您可以说“我需要包 org.foo”或“我需要一个实现 org.bar 的 OSGi 服务”，配置程序将决定哪些捆绑包最适合您的要求。 OBR 比 Karaf 功能更灵活、更通用，但如果您只是将一组明确定义的捆绑包安装到已经准备好所需基础设施的框架中，那么它可能有点过大了。如果组成应用程序的捆绑包彼此之间没有依赖关系，它也对您没有帮助 - 您仍然需要将它们全部包含在您的“起始集中”中。
区别有点模糊，因为 Karaf 功能允许您在 Maven URL 中指定版本范围，因此即使使用某个功能，您也可以在配置内容方面更加灵活。 Karaf 功能还具有与 OBR 的互操作性，因此您可以根据 OBR 要求编写功能定义文件。
我相信 Karaf Cave 是一个具有一些特性的 OBR 实现。所以它是一个服务器，而不是像功能或 OBR 配置这样的新“技术”。
--
企业 OSGi 实际应用：http://www.manning.com/cummins
Karaf features and OBR are different ways of solving the (sort of) same problem. Both allow you to install OSGi bundles into an OSGi framework, but how they decide which bundles to install is different.
With a Karaf feature, you provide a file (feature.xml, say) which explicitly lists URLs for all the bundles for the feature. They can live on the filesystem, or in a maven repository, or anywhere else which can be described by a URL.
OBR, on the other hand, works out what bundles to work out based on requirements and capabilities. It will work out the transitive dependencies of whatever you're installing as your starting point and make sure they all get installed. Usually you'd configure one or more external repositories which support the OBR format, and then an OBR resolver in your runtime would provision bundles from those repositories. So you can say "I need package org.foo" or "I need an OSGi service which implements org.bar" and the provisioner will decide which bundles best suit your requirements. OBR is more flexible and generic than Karaf features, but it might be overkill if you're just installing a well-defined set of bundles into a framework which is already primed with the infrastructure you need. It also doesn't help you if the bundles which make up your application don't have dependencies on each other - you'll still need to include them all in your 'starting set'.
The distinction gets a bit blurred, because Karaf features allow you to specify version ranges in the maven URLs, so even with a feature you can be a bit flexible in what gets provisioned. Karaf features also have an interoperability with OBR so you can write your feature definition file in terms of OBR requirements.
I believe Karaf Cave is an OBR implementation with some feature-features. So it's a server rather than a new 'technology' like features or OBR provisioning.
--
Enterprise OSGi in Action: http://www.manning.com/cummins