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é <[email protected]>: >> >>> 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é >>> [email protected] >>> 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/)
