karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [Discuss] Improvements in karaf feature handling
Date Thu, 20 Aug 2015 13:57:29 GMT
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é <jb@nanthrax.net>:

> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message