Skip to end of metadata
Go to start of metadata


Apache Karaf has the concept of feature repositories and features that help a lot in installing complex frameworks with lots of dependencies.

  • Feature repository: An xml file that describes 1..n features.
  • Feature : Something you can install. Can depend on bundles and other features. If you install a feature then all its dependencies will also be installed. 

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.

  • OBR Repository: A list of bundles and their requirements / capabilties
  • Resource: Something that can be installed. In most cases a bundle.
  • Requirement: A description of something a resource needs. For example it can be a package import or that the code needs Java 8
  • Capability: A description of something a resource offers

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></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.






Twitter: @schneider_chris

Github: cschneider



Popular Labels

My colleagues at Talend

Talend Community Coders

  • No labels