I currently use karaf with artifactory as my osgi jar repository. This works well. I have come across the Apache Cave tool for Karaf which very much looks like a repository except that it can also be stored in a database or other datasource instead of a filesystem.
What value does this provide. What are some of the usecases that can be solved using Cave
Disclaimer: I'm not involved in development of OSGi specs or Apache Cave. Everything below is only my conclusions based on personal experience.
Apache Cave is reference implementation of OSGi Repository spec. The latter in turn solves problems of OSGi bundles provisioning. It is supposed to work in the following way: it provides a repository descriptor, which defines a set of resources (usually they are bundles), capabilities they provide, and requirements they require. This meta-information is used to automatically provision dependencies when you deploy some resource.
Details are explained in the specification https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf, section 132.
Situation around OSGi repository seems quite shady for me. Apache Cave is a provider of OSGi repository, but I didn't found any suitable client for it. My question, Karaf Cave vs org.apache.felix.bundlerepository, still remain unanswered.
There are several alternatives. Apache Felix has its own implementation (org.apache.felix.bundlerepository), which is very similar by concept, but not fully compatible with the spec (info may be outdated and needs check). Karaf solves the same problem with Features facility.
What value does this provide? What are some of the usecases that can be solved using Cave?
Cave is used to store Repositories which contain important information (such as location, version, requirements, capabilities, ...) about bundles (or artifacts in general). It's one of the 3 important pieces in resolving process. The other 2 are Resolver and Resolve Context.
The Resolver is what you may know from OSGi runtime. It is the thing that tells you if your bundle's requirements are met (so it can be started). To do so it talks to a Resolve Context to get to know what is available, what is expected, what is optional, etc. The Resolve Context would in turn consult one or more Repositories to get to know what bundles are available. Quite often those are only the bundles installed in your runtime. However it is possible to have a runtime that would use Repository referring to external artifacts that can be installed when Resolver determines they are needed.
Roughly the same concept can be used at build time. Bnd project for example allows you to define .bndrun files which are kind of properties based version of Resolve Context. One of the things you can provide inside them is Repositories that have information about available bundles. Such repositories could be served by Cave (or anything else, including local XML file). Based on that information Bnd can assemble a runtime for you (tell you which bundles you need based on what bundle(s) you want to run).
Furthermore, Cave can act as Maven repository or proxy to other Maven repositories. That comes handy as you could use Cave as "single point of contact" for both Resolver and traditional Maven dependencies.
