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/> >
