servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré>
Subject Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles
Date Mon, 30 Jan 2017 17:25:27 GMT
Good point. But I don't see an easy move without a change on the git layout.


On 01/30/2017 06:18 PM, Guillaume Nodet wrote:
> I don't really get the idea of separating the features from the bundles
> from a code source point of view...
> In the arguments you listed in your first email, having a separate
> lifecycle is great, we can even have a different groupId.
> Though it may be easier to maybe move things into 2 separate directories :
>    bundles/
>    features/
> Even if they have different lifecycles, I think they will be released as
> batches, same as it's happening for bundles, so I think it would have been
> easier to have them in a single repo.
> That said, it's definitely no big deal.
> 2017-01-30 18:13 GMT+01:00 Jean-Baptiste Onofré <>:
>> Yes, it's the idea: move features on git, each module there with its own
>> release cycle.
>> Regards
>> JB
>> On 01/30/2017 06:11 PM, Krzysztof Sobkowiak wrote:
>>> Hi
>>> I propose the servicemix-features subproject/repository (or you meant
>>> something other?) We could move there later some other features from
>>> ServiceMix which have another lifecycle than the assembly (e.g. the
>>> activiti  /here the activiti proiect could be more suitable/ or drools
>>> feature) and place there some new future features. In this case this
>>> repository should also contain eventual glue code necessary to implement
>>> the feature.
>>> I propose to migrate the old
>>> sf/servicemix/smx4/features/ repository to git (servicemix-features),
>>> move the old code to servicemix4 branch and start with an empty master fr
>>> the new features.
>>> Kindly regards
>>> Krzysztof
>>> On 30.01.2017 12:57, Jean-Baptiste Onofré wrote:
>>>> 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.
>>>> 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
>>>>> 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é
>> Talend -

Jean-Baptiste Onofré
Talend -

View raw message