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