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
