karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject [Discuss] Improvements in karaf feature handling
Date Thu, 20 Aug 2015 13:08:34 GMT
Currently karaf features are done in a way that each feature is 
consistent in itself.
While this makes the features easy to install I think the big problems 
is that this creates a coupling between features that should not be 

As an example consider the transaction and jpa features.

transaction -> persistence-api [1.1,2)
jpa -> persistence-api [1.1,2)

So both of them depend on the persistence-api feature. All three 
features currently are in the enterprise feature shipped with karaf.
The problem is that this creates a tight coupling between the karaf 
version and the aries jpa and aries transaction versions. The problem is 
similar with other
features like hibernate, openjpa, ...

Currently we provide several feature versions in the same feature file 
to give the user a bigger choice in what to install. The big problem 
there is though that we can not
include all the possible versions and of course we can not include 
versions that are not yet released. So when a customer hits a bug in any 
of the bundles he can not easily upgrade to a new version of say aries jpa.

So what I would like to do is create features in the place where the 
software is released and have as loose coupling between the modules as 
So for example I would like to create a the aries transaction feature 
file in the aries transaction module and the aries jpa feature file in 
the aries jpa module. So whenever a release of these is done there is 
also a  new feature file that makes the newest release available to 
users. So they do not need to wait until a new karaf version picks up 
the new aries jpa release.

So in the aris jpa feature file I would put the jpa feature but I do not 
want to have a dependency on the aries jpa feature file.
At the moment this is not possible as I need to define a reference to 
the persistence-api feature to make the aries jpa featur consistent.

So I wonder if we could allow features to kind of have open 
requirements. Like the aries jpa feature would have an open requirement 
on the package javax.transaction [1.1,2) possibly also a requirement for 
a TransactionManager service. These requirements would not even have to 
be defined as the bundles contain all the needed information.

Then when I try to install the jpa feature in karaf the feature service 
could tell me that there are the unresolved requirements above. It could 
then even go through all other features and propose the ones that offer 
the respective capabilities. So it could work like this:
 > feature:install jpa
Unresolved requirements:
Package: javax.persistence [1.1,2)
Service: javax.transaction.TransactionManager
The requirements can be resolved when also installing
1. transaction transaction-api/1.1
2. transaction transaction-api/1.2

In an interactive mode the user could then select the features to also 
install from the list. In a non interactive mode there would just be an 
error and the user would have to add the features to the command.

In the same way it would work for a whole set of features:
 > feature:install jpa/2.1.1 hibernate/4.3.6.Final
Unresolved requirements:
Package: javax.persistence [1.2,2)
Service: javax.transaction.TransactionManager
The requirements can be resolved when also installing
1. transaction transaction-api/1.2

In this case as there is only one solution the feature service could 
even auto install the necessary features without them being mentioned in 
any of the features to be installed. So it would act a bit like and OBR 
on feature level.

I think it would make much more sense to handle features like this than 
how we do it right now. It would allow to use the new requirements and 
capabilties and the new resolver much better. At the same time the 
features themselves would become much more loosely coupled and easier to 



Christian Schneider

Open Source Architect

View raw message