On Oct 11, 2012, at 1:22 PM, Achim Nierbeck wrote: > Yeah, I remember all those discussions about this topic also ... > > ... (dreaming of a perfect world) > Aries and all the other depending projects produce features.xml artifacts ... > (dream is over)
Since the subsystem spec is out that is not going to happen. Karaf could use subsystems and drop its proprietary feature concept however. david jencks > > unfortunately almost all non karaf-related projects produce feature files, > therefore we have to take care of it then. > I'm not sure about the proposed artifacts beeing coupled to tight to > karaf release > schedule (Andreas' idea of 3.x.y for Karaf 3.x version) > I'd rather not do this, cause it just wouldn't help much on the issue. > > We should try to get those needed features either into the Projects > where we do have some influence, like aries, pax-web (I'm actually working on > this to decouple this stuff ;) ) and for all the others like spring > we might just need something similar to what servicemix got for the > osgi-fied bundles. > > So lets take the spring features.xml as the reference sample (since it > did get this stuff started). > > <features name="spring-2.5.6"> > <feature name="spring-core" version="2.5.6"> > .... > </features> > > and the maven artifact could be something like the following: > > <groupId>org.apache.karaf.features</groupId> > <artifactId>spring-2.5.6</artifactId> > <version>1.0.1</version> > > > for the other spring versions basically the same. > > regards, Achim > > > 2012/10/11 Scott England-Sullivan <sully6...@gmail.com>: >> For those just joining us, the original thread was: >> http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html >> >> That sounds like a good solution. One question though. If you move >> all the Karaf compatible "extensions" to a sub-group, wouldn't you >> still encounter the same type of hold up? For example, holding up an >> Aries enterprise release with a critical bug fix due to ongoing >> integration of a new Spring release. >> >>> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <anpie...@gmail.com> wrote: >>> >>>> ah, and last but not least: we might want this discussion to be held >>>> on the dev list. >>>> >>>> Kind regards, >>>> Andreas >>>> >>>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <anpie...@gmail.com> wrote: >>>>> OK, now that I finally found my way through the original thread >>>>> causing this discussion I'm even stronger +1 for this topic than >>>>> before. >>>>> >>>>> Get out everything out of the core release which is not started by >>>>> default in the default apache-karaf distribution. >>>>> >>>>> To make things easy for us we might pack all those other features and >>>>> commands and so on into a single release structure to make it easy for >>>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf >>>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions. >>>>> This should make the vote & the release process easy enough for us AND >>>>> since we can version the features independently of the full release >>>>> versions the user can still mix them as he sees fit. >>>>> >>>>> Just something else to get the discussion about this going :-) >>>>> >>>>> Kind regards, >>>>> Andreas >>>>> >>>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <anpie...@gmail.com> >>>>> wrote: >>>>>> Well, IIRC we've discussed this already on IRC some time ago about >>>>>> that. One the main problems by this was that we need to release all of >>>>>> those separately; which adds quite some work. >>>>>> >>>>>> But basically I'm with you. It's a PITA with those spring & aries >>>>>> enterprise feature upgrades and that we have to wait for them. IMHO we >>>>>> should really re-discuss this issue again; to move anything not >>>>>> required into different features. Thanks to Christians searchurl >>>>>> feature we could still make it pretty easy for ppl to add them >>>>>> afterwards if they like. This wouldn't make too much difference to how >>>>>> we're handling it right now anyhow... >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Kind regards, >>>>>> Andreas >>>>>> >>>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan >>>>>> <sully6...@gmail.com> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> In a recent thread on the development list there was a discussion >>>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it >>>>>>> up to accommodate an update to Spring 3.1. It struck me; why is Karaf >>>>>>> tied to a 3rd party release at all? Why isn't the modular container >>>>>>> itself modular? Why aren't 3rd party support modules such as Spring >>>>>>> deployers externalized and allowed to progress at their own pace? >>>>>>> Third party dependent modules should be developed against a given >>>>>>> release of Karaf, they shouldn't drive it. There is a new >>>>>>> karaf-webconsole project so the precedence is there. >>>>>>> >>>>>>> Karaf is a great, light-weight container which put a nice manageable >>>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and >>>>>>> IMHO should stay focused on just that at its core. The capabilities >>>>>>> that are tied to simplifying 3rd party support are goodness but not >>>>>>> required and as such, shouldn't drive the cores development. >>>>>>> >>>>>>> Now maybe you really can't separate one from the other though I don't >>>>>>> see where it is tightly coupled at. I also understand it is a greater >>>>>>> challenge to manage because the project become fractured but maybe >>>>>>> Karaf is at that point. >>>>>>> >>>>>>> In reality I am good either way but thought it was worth discussing. >>>>>>> >>>>>>> Best Regards, >>>>>>> Scott ES >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Scott England-Sullivan >>>>>>> Apache Camel Committer >>>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc. >>>>>>> FuseSource is now part of Red Hat >>>>>>> Web: fusesource.com | redhat.com >>>>>>> Blog: sully6768.blogspot.com >>>>>>> Twitter: sully6768 >> >> - >> Scott England-Sullivan >> Apache Camel Committer >> http://sully6768.blogspot.com > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer & Project Lead > OPS4J Pax for Vaadin > <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project > Lead > blog <http://notizblog.nierbeck.de/>
