servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof Sobkowiak <krzys.sobkow...@gmail.com>
Subject Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles
Date Mon, 30 Jan 2017 17:28:35 GMT
Maybe the servicemix-bundles name i not to good anymore when it should contain both bundles
and features.

On 30.01.2017 18:25, Jean-Baptiste Onofré wrote:
> Good point. But I don't see an easy move without a change on the git layout.
>
> Regards
> JB
>
> 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é <jb@nanthrax.net>:
>>
>>> 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 https://svn.apache.org/repos/a
>>>> 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
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
>>>
>>
>>
>>
>

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

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