karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott England-Sullivan <sully6...@gmail.com>
Subject Re: 3rd Party Feature Definitions
Date Thu, 11 Oct 2012 17:35:23 GMT
I will move it back over. Wasn't sure where to start. 

Scott England-Sullivan
blog:sully6768.blogspot.com twitter:@sully6768

On Oct 11, 2012, at 12:14 PM, Andreas Pieber <anpieber@gmail.com> 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 <anpieber@gmail.com> 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 <anpieber@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
>>> <sully6768@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

Mime
View raw message