karaf-dev 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:36:15 GMT
Moving to Dev.

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

View raw message