Apache Karaf has the concept of feature repositories and features that help a lot in installing complex frameworks with lots of dependencies.
So this is the concept of karaf up to version 3. In karaf 4 there are new possibilities as the feature service now uses the OSGi resolver. This means that karaf can now also resolve features based on requirements and OBR repositories.
So the resolver allows karaf to resolve the full list of bundles to be installed based on some list of top level requirements. The current features do not yet use this as there are no default OBR repositories to choose bundles from.
Current usage of the resolver
Karaf 4 features already use the resolver to avoid installing duplicate versions of bundles like specs. It works by setting dependency=true on some bundles. All bundles with dependency=false or true form the repository to choose from. The top level requirements are the bundles with dependency=false (which is the default). The bundles with dependency=true will then only be installed if the resolver decides they are needed. So this forms a kind of poor man OBR repository.
Proposal: Using OBR repository indexes in feature repos
We could make it a lot easier to create features and also reuse them in bndtools if we would use one OBR index per feature repo file.
Tim Ward currently works on an bnd-indexer-maven-plugin that allows to create an OBR index from a pom with a list of dependencies. The output is an OBR index file that is then deployed to maven.
So we could add a new Element to the feature repo xml like <obr-repository>mvn:com.my.company/myrepo/2.1.1</obr-repository>.
This would add the OBR index to karaf as soon as the feature repo is added.
Then the feature descriptions only would need to list some top level bundles and could also list any requirements.
Further improvements to make features easier to create and maintain
The mvn uris for bundles in feature repos are quite difficult to write and maintain. As the OBR index gives us a nice base we could write bundles in a more concise way. Bndtools uses a syntax where they just list the symbolic name of a bundle and optionally a version range.
We might also allow people to create bndrun files using bndtools and offer a maven plugin to create features out of these. That would allow to use the graphical tooling of bndtools.
Another possible representation for features would be the subsystem descriptors. They also use a similar syntax to describe root bundles and can use OBR to resolve. Feature type subsystems should also be fairly similar to karaf features.
My colleagues at Talend