我目前使用带有artifactory的karaf作为我的osgi jar存储库。这很好用。我遇到过针对Karaf的Apache Cave工具，除了它还可以存储在数据库或其他数据源而不是文件系统中之外，它看起来像一个存储库。
这提供了什么价值。使用Cave
可以解决哪些用例答案 0 :(得分：1)
免责声明：我没有参与开发OSGi规范或Apache Cave。以下所有内容仅仅是基于个人经验的结论。
Apache Cave是OSGi Repository规范的参考实现。后者反过来解决了OSGi捆绑配置的问题。它应该以下列方式工作：它提供了一个存储库描述符，它定义了一组资源（通常是捆绑包），它们提供的功能以及它们所需的需求。此元信息用于在部署某些资源时自动提供依赖关系。
详细说明在规范https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf第132节中解释。
围绕OSGi存储库的情况对我来说似乎很阴暗。 Apache Cave是OSGi存储库的提供者，但我没有为它找到任何合适的客户端。我的问题Karaf Cave vs org.apache.felix.bundlerepository仍然没有答案。
有几种选择。 Apache Felix有自己的实现（org.apache.felix.bundlerepository），它在概念上非常相似，但与规范不完全兼容（信息可能已过时且需要检查）。 Karaf解决了与功能设施相同的问题。
答案 1 :(得分：0)
这提供了什么价值？使用Cave可以解决哪些用例？
Cave用于存储Repositories，其中包含有关包（或一般工件）的重要信息（如位置，版本，要求，功能......）。它是解决过程中的三个重要部分之一。其他2个是Resolver和Resolve Context。
您可以从OSGi运行时了解Resolver。这是告诉您是否满足您的捆绑要求（因此可以启动）的事情。为此，它会与Resolve Context进行对话，以了解可用内容，预期内容，可选内容等。Resolve Context将咨询一个或多个Repositories以获取了解哪些捆绑包可用。通常这些只是运行时中安装的捆绑包。但是，可能有一个运行时使用Repository引用可在Resolver确定需要时安装的外部工件。
在构建时可以使用大致相同的概念。例如，Bnd项目允许您定义.bndrun个文件，这些文件是基于属性的Resolve Context版本。您可以在其中提供的一项内容是Repositories，其中包含有关可用捆绑包的信息。这些存储库可以由Cave （或其他任何东西，包括本地XML文件）提供。根据该信息Bnd可以为您组装运行时（根据您想要运行的捆绑包，告诉您需要哪些捆绑包）。
此外，Cave可以充当Maven存储库或其他Maven存储库的代理。这很方便，因为您可以将Cave用作Resolver和传统Maven依赖项的“单点联系”。