I think this general problem already has a clean solution. I'd like to keep features transitively closed, so that they can easily be installed without any additional requirements. To open them up, it's just a matter of specifying the dependency="true" flag on the required features. The resolver will then only use them as one possible way to solve the requirements expressed by other bundles.
2015-08-20 15:15 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > By the way, about Cave, it's exactly the way that you describe: Cave is an > OSGi Repository implementation (basically OBR), that the features resolver > can use. > > I created a Jira to document this and I have a blog post in progress to > explain how it works. > > Regards > JB > > > On 08/20/2015 03:13 PM, Jean-Baptiste Onofré wrote: > >> Hi Christian, >> >> and what about if the persistence-api feature provides a capability >> (more generic) and transaction/jpa just have a requirement ? >> >> It's the way that we improved the pax-web feature to be able to deal >> with jetty or tomcat without coupling to jetty or tomcat features. >> >> About the version, I agree that it would be better to externalise the >> features repositories and not embed them (and use repo-add to add the >> feature that we need). It was the purpose of Cave: provide a Karaf >> Feature Respository manager: instead of embedding the features, Karaf >> can be just a client to Cave providing all features (with different >> version). It's also the step forward that we started as Cave can be a >> feature resource repository (that you can add in >> etc/org.apache.karaf.features.cfg using the resourcesRepository property). >> >> Regards >> JB >> >> On 08/20/2015 03:08 PM, Christian Schneider wrote: >> >>> 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 >>> directly >>> related. >>> >>> 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 >>> possible. >>> 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 >>> maintain. >>> >>> WDYT? >>> >>> Christian >>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
