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