Mailing-List: contact dev-help@servicemix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@servicemix.apache.org
Subject: Re: [Discuss] Create one karaf feature repo per spring version in
 servicemix bundles
To: dev@servicemix.apache.org, Karaf Dev <dev@karaf.apache.org>
References: <03842715-5ee1-380d-57d0-3ce7ebbfab11@die-schneider.net>
From: =?UTF-8?Q?Jean-Baptiste_Onofr=c3=a9?= <jb@nanthrax.net>
Message-ID: <eeb16c4a-522a-202f-012a-bfcea3aad87e@nanthrax.net>
Date: Mon, 30 Jan 2017 12:57:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <03842715-5ee1-380d-57d0-3ce7ebbfab11@die-schneider.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Mon, 30 Jan 2017 11:57:18 -0000

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