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
