You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Christian Schneider <ch...@die-schneider.net> on 2017/01/30 11:09:18 UTC

[Discuss] Create one karaf feature repo per spring version in servicemix bundles

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

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Christian Schneider <ch...@die-schneider.net>.
Normally not but when an error in the bundling is discovered it can happen.

Christian

On 30.01.2017 13:52, Guillaume Nodet wrote:
> 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 ?
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Guillaume Nodet <gn...@apache.org>.
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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Guillaume Nodet <gn...@apache.org>.
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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by 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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Guillaume Nodet <gn...@apache.org>.
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
>



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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Guillaume Nodet <gn...@apache.org>.
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
>



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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
I have requested the new repo https://issues.apache.org/jira/browse/INFRA-13458

Kindly regards
Krzysztof

On 31.01.2017 22:25, Krzysztof Sobkowiak wrote:
> So, I'll let create the repository for features
>
> Kindly regards
> Krzysztof
>
> On 30.01.2017 18:36, Jean-Baptiste Onofr� wrote:
>> That's my point in the previous e-mail. For spring, the feature is "coupled" to the bundles. But we can imagine to provide features not related to SMX bundles (like activity or drools for instance, when the other project doesn't provide the features itself of course).
>>
>> Regards
>> JB
>>
>> On 01/30/2017 06:33 PM, Krzysztof Sobkowiak wrote:
>>> But if we would like to add in the future new features (not always connected to the bundles contained in the bundles repository like in this spring case) I'd prefer to separate them from the bundles repository.
>>>
>>> On 30.01.2017 18:28, Krzysztof Sobkowiak wrote:
>>>> 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/)

-- 
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/)

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
So, I'll let create the repository for features

Kindly regards
Krzysztof

On 30.01.2017 18:36, Jean-Baptiste Onofr� wrote:
> That's my point in the previous e-mail. For spring, the feature is "coupled" to the bundles. But we can imagine to provide features not related to SMX bundles (like activity or drools for instance, when the other project doesn't provide the features itself of course).
>
> Regards
> JB
>
> On 01/30/2017 06:33 PM, Krzysztof Sobkowiak wrote:
>> But if we would like to add in the future new features (not always connected to the bundles contained in the bundles repository like in this spring case) I'd prefer to separate them from the bundles repository.
>>
>> On 30.01.2017 18:28, Krzysztof Sobkowiak wrote:
>>> 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/)

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
That's my point in the previous e-mail. For spring, the feature is 
"coupled" to the bundles. But we can imagine to provide features not 
related to SMX bundles (like activity or drools for instance, when the 
other project doesn't provide the features itself of course).

Regards
JB

On 01/30/2017 06:33 PM, Krzysztof Sobkowiak wrote:
> But if we would like to add in the future new features (not always connected to the bundles contained in the bundles repository like in this spring case) I'd prefer to separate them from the bundles repository.
>
> On 30.01.2017 18:28, Krzysztof Sobkowiak wrote:
>> 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/)
>

-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
But if we would like to add in the future new features (not always connected to the bundles contained in the bundles repository like in this spring case) I'd prefer to separate them from the bundles repository.

On 30.01.2017 18:28, Krzysztof Sobkowiak wrote:
> 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/)

-- 
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/)

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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/)

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
>>
>
>
>

-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Guillaume Nodet <gn...@apache.org>.
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
>



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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by 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/asf/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.bundles.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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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/asf/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.bundles.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
>>
>

-- 
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/)

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by 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.bundles.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

Re: [Discuss] Create one karaf feature repo per spring version in servicemix bundles

Posted by 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.bundles.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