karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: 3rd Party Feature Definitions
Date Thu, 11 Oct 2012 16:54:38 GMT
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...


Kind regards,

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