L.S.,
Yeah, that sounds better (less hacky ;)) - I raised https://issues.apache.org/jira/browse/SM-2262 to keep track of that change. Regards, Gert On Tue, Mar 4, 2014 at 10:08 PM, Krzysztof Sobkowiak <[email protected]> wrote: > I would suggest 'internal' instead of 'overrides'. The features repository > should contain not only the overrides but also servicemix features which are > not intended to be installed in other distributions, e.g. any servicemix > specific commands or configurations > > > On 24.02.2014 22:10, Gert Vanthienen wrote: >> >> Hi Krzysztof, >> >> >> Yeah, if we have to add those kinds of overrides again, it would >> definitely make sense to move those into a separate file as well. >> Looks like we still have one such feature around with the jax-rs >> feature in that file (not sure that one is still required though). >> Perhaps we should call that feature 'overrides' or something like that >> to clarify what it does? >> >> >> Regards, >> >> Gert Vanthienen >> >> >> On Mon, Feb 24, 2014 at 9:53 PM, Krzysztof Sobkowiak >> <[email protected]> wrote: >>> >>> Hi Gert >>> >>> Yes, my proposal is to split the features. Probably now we have nothing >>> what >>> could be placed in core features, but I give you an example. Some weeks >>> ago >>> we had some activemq features overwritten in servicemix features. If I >>> want >>> to include servicemix features in my distribution or include them in >>> vanilla >>> Karaf, I want to have such features like Activiti or Akka, not >>> overwritten >>> ActiveMQ features. I'll probably use another version of ActiveMQ. The >>> overwritten ActiveMQ features were very servicemix specific. The purpose >>> of >>> core features is a place for such features which are necessary tobuild >>> the >>> servicemix distribution and could make problems if they were included in >>> the >>> "public" features. We can live with one features file (+ separate file >>> for >>> examples). But when we need to define in the future some features like >>> these >>> for ActiveMQ, they must be placed in separate file. >>> >>> Best regards >>> Krzysztof >>> >>> >>> >>> On 24.02.2014 21:01, Gert Vanthienen wrote: >>>> >>>> Hi Krzysztof, >>>> >>>> >>>> So, just to be clear, the proposal is to split up what we have in >>>> assemblies/src/main/filtered-resources/features.xml into multiple >>>> features descriptor (cfr. >>>> >>>> >>>> http://svn.apache.org/viewvc/servicemix/smx5/trunk/assemblies/src/main/filtered-resources/features.xml?view=markup), >>>> right? >>>> >>>> Not sure how you would discriminate between the first two things >>>> you're proposing - shouldn't any feature we build be installable on >>>> another Karaf distribution anyway? Perhaps we can just keep those two >>>> together for now: if I look at the current features.xml file, it could >>>> contain everything that doesn't start with example-*. How about just >>>> keeping the name for that one the same as it is right now? >>>> apache-servicemix-<version>-features.xml seems to match the pattern >>>> that other projects use for their descriptor pretty well already. >>>> >>>> If we want, we can definitely move the examples into a separate >>>> features files. It would make it easier for people to add the Apache >>>> ServiceMix features to their distribution without introducing the >>>> examples (which they're probably not interested in in that scenario >>>> anyways). So I'm +1 for moving those features apart, perhaps we can >>>> just attach it with another classifier, >>>> apache-servicemix-<version>-examples.xml perhaps? >>>> >>>> In my mind, we can best do that right now in the ServiceMix 5 codebase >>>> as well. I assume we want to branch that off into a Karaf 3.x based >>>> ServiceMix 6 line pretty soon anyway, so the more of these changes we >>>> do now, the more these two lines of code are alike and the easier we >>>> will make it for ourselves to merge changes back and forth afterwards. >>>> >>>> >>>> Regards, >>>> >>>> Gert Vanthienen >>>> >>>> >>>> On Fri, Feb 21, 2014 at 8:33 PM, Krzysztof Sobkowiak >>>> <[email protected]> wrote: >>>>> >>>>> Hi >>>>> >>>>> In the discussions about the ServiceMix future and the future of >>>>> ServiceMix >>>>> features it was mentioned about moving some non-core features into the >>>>> Karaf >>>>> Enterprise Features subproject. Another people think, the Karaf >>>>> subproject >>>>> is not too good place for such features like Activiti. Such features >>>>> could >>>>> be also extracted into a separate subproject in ServiceMix which could >>>>> have >>>>> a separate lifecycle, but we don't have too many such features to >>>>> create >>>>> a >>>>> subproject for them. >>>>> >>>>> In the code base for ServiceMix 6 (working version for the Karaf 3.x >>>>> line >>>>> as >>>>> not decided yet which version will have the SMX based on Karaf 3.x) I'd >>>>> like >>>>> to prepare 3 feature repositories >>>>> >>>>> * servicemix-core - core features which will be integral part of >>>>> servicemix, not installable on other Karaf distributions >>>>> * servicemix-esb - non-core features like current Activiti >>>>> integration >>>>> or missing connection factory for ActiveMQ. This repository should >>>>> provide features which will be used to build the ServiceMix >>>>> distribution and which can be also used outside the ServiceMix >>>>> distribution, e.g. in Karaf. It should have no dependency to core >>>>> ServiceMix. Currently we have not too many such features and some >>>>> of >>>>> them could be moved into the original project or into the Karaf >>>>> Enterprise Features subproject (but id doesn't exist yet and many >>>>> people doesn't like the idea for moving the esb specific features >>>>> into Karaf). In the future we can have more esb features and we >>>>> can >>>>> extract a separate subproject having own lifecycle, >>>>> * servicemix-examples - I think, the examples should be separated >>>>> from >>>>> other features >>>>> >>>>> What do you think about this idea? >>>>> >>>>> Best regards and have a nice weekend >>>>> Krzysztof >>>>> > > -- > Krzysztof Sobkowiak > > JEE & OSS Architect | Technical Architect @ Capgemini > Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center > <http://www.pl.capgemini-sdm.com/> | Wroclaw > e-mail: [email protected] <mailto:[email protected]> | > Twitter: @KSobkowiak
