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