to get a real good impression on what can be done with the subsystem spec I'd have to take a deeper look at it first, so I can't tell right now :) but it could be promising.
about @Andreas' fears "of the hassle to release and vote on all those" I'd say this probably is just once for a big load of features and after that ever now and then maybe one will increase / upgrade. Taking Spring into account this won't be that often I think, and pax-web will surely be hosted at pax-web, that's for sure :) regards, Achim 2012/10/12 Andreas Pieber <[email protected]>: > well, subsystems sounds like a reasonable goal for Karaf 4.0. In the > meantime Achim's proposal sounds quite valid. Independently I'm still > a bit afraid of the hassle to release and vote on all those > separately... > > Kind regards, > Andreas > > On Fri, Oct 12, 2012 at 2:11 AM, David Jencks <[email protected]> wrote: >> >> 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 <[email protected]>: >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 >>>>>>>> <[email protected]> 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/> >> -- 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/>
