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] Create one karaf feature repo per spring version in servicemix bundles
Date Mon, 30 Jan 2017 12:52:07 GMT
Or we could do that per minor version.  I'm not sure we really need to
support more than one micro version per minor version. Do we ?

2017-01-30 13:14 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> The range helps only for "minor" version, the features repo will be:
>
> <feature name="spring" version="4.3.5.RELEASE_1">
>         <bundle>mvn:.../4.3.5.RELEASE_1</bundle>
> </feature>
>
> and another for:
>
> <feature name="spring" version="4.3.6.RELEASE_1">
>         <bundle>mvn:.../4.3.5.RELEASE_1</bundle>
> </feature>
>
> Regards
> JB
>
>
> On 01/30/2017 01:09 PM, Guillaume Nodet wrote:
>
>> 2017-01-30 12:57 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>
>> Hi Christian,
>>>
>>> adding the Karaf dev mailing list in copy.
>>>
>>> I agree with the proposal.
>>>
>>> Now, SMX Bundles are supposed to contain only OSGi bundle wrapper for non
>>> OSGi libaries (and jar generally speaking).
>>> As it's where we provide Spring bundles, it would be logic to have the
>>> corresponding feature, however, I see two issues:
>>>
>>> 1. It means that SMX Bundles will contain more than just bundle, it will
>>> also provide features. It would be weird for users to have a feature in
>>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bund
>>> les.spring/4.3.5.RELEASE_1/xml/features URL for instance.
>>> 2. It means we will have one feature module for each sub-spring version:
>>> for instance 4.3.5_1 and 4.3.5_2.
>>>
>>>
>> We may be able to work around the problem by using maven range in the
>> feature definition.
>>
>> For example:
>>
>>  <feature name="spring" version="4.3.5">
>>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bund
>> les.spring-core/[4.3.5,4.3.6)</bundle>
>>   ...
>> </feature>
>>
>> This should allow to release the feature only once.
>>
>>
>> It's not a big deal because it happens rarely, but it happened already.
>>>
>>> If you take a look on Cave README, you will see:
>>>
>>> "Apache Karaf Cave is an Apache Karaf subproject. It provides an OSGi
>>> Bundle Repository (OBR) and Karaf Features Repository (KFR)."
>>>
>>> The purpose of a Karaf Features Repository (KFR) is to host non core
>>> Karaf
>>> features, not in other project.
>>>
>>> So, instead of org.apache.servicemix.bundles, where the Spring bundles
>>> will stay, I would propose a org.apache.servicemix.features, acting as a
>>> repository, wrapping different features. We would have:
>>> - org.apache.servicemix.features/spring
>>> - org.apache.Servicemix.features/directory
>>> - ...
>>>
>>> Each SMX features would have its own release cycle, and can have branches
>>> for the different versions.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 01/30/2017 12:09 PM, Christian Schneider wrote:
>>>
>>> Hi all,
>>>>
>>>> we are currently trying to make Apache Karaf slimmer for the version
>>>> 4.1.0.
>>>>
>>>> In previous karaf versions we had different spring versions in the karaf
>>>> spring feature repo. This posed two problems:
>>>> 1. The karaf resolver always has to work on all provided spring versions
>>>> which increased the chance a wrong one is picked
>>>> 2. Karaf can not provide all bugfix versions of spring. So each karaf
>>>> version comes with a different set. So for a user the upgrade means the
>>>> spring version
>>>> changes and he can not upgrade the bugfix version while keeping the
>>>> karaf version.
>>>>
>>>> So starting with karaf 4.1.0 we split the spring feature repos into the
>>>> most current version (currently 4.3.5) which is installed by default and
>>>> a spring-legacy feature repo with the older versions. This fixes problem
>>>> 1 but also causes problems for some existing features like the activemq
>>>> 5.14.3 one that requires spring 3.
>>>>
>>>> So a better fix would be to provide one feature repo per spring version
>>>> and let the 3rd party feature add this to its feature using the
>>>> repository tag. So only the needed spring version is provided and the
>>>> maintainer of the 3rd party repo can freely decide which to use.
>>>>
>>>> The problem with this is that karaf is not a good place to provide the
>>>> feature repos as we release all of karaf together in one version.
>>>>
>>>> So I think servicemix bundles would be a good place to put these feature
>>>> repos into. The source repo already provides the spring bundles for each
>>>> version and I think the feature repo would fit nicely into this
>>>> structure.
>>>>
>>>> If the activemq community likes the idea I will provide pull requests
>>>> for the spring versions we currently use in karaf.
>>>>
>>>> Christian
>>>>
>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet

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