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
