camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Anstey <jans...@gmail.com>
Subject Re: [DISCUSS] Upgrade Camel to Karaf 4
Date Tue, 27 Sep 2016 19:25:24 GMT
+1

On Fri, Sep 23, 2016 at 11:47 AM, Andrea Cosentino <
ancosen1985@yahoo.com.invalid> wrote:

> I agree with Daniel.
>
> Anyway this is something we can surely work on for the next release.
>  --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Friday, September 23, 2016 4:15 PM, Daniel Kulp <dkulp@apache.org>
> wrote:
>
> I think it’s too late to do this for 2.18 (trying to get that out soon).
> Might make sense for 2.19.
>
> Dan
>
>
>
> > On Sep 23, 2016, at 4:21 AM, Guillaume Nodet <gnodet@apache.org> wrote:
> >
> > I'd like to start a discussion around upgrading Camel karaf support to
> > Karaf 4.
> > Karaf 4 has brought a number of changes that could be leveraged :
> >  * no strong dependency on blueprint
> >  * complete feature validation at build time
> >  * more fine grained feature so that all dependencies can be expressed
> >
> > I'd like to leverage those for Camel.  This can be achieved either by
> > dropping support for Karaf 2 and 3, or by keeping both (effectively
> > duplicating the integration code in platforms/karaf to platforms/karaf4).
> >
> > Also, it would make sense to upgrade to cxf 3.2-SNAPSHOT which I'm also
> > upgrading to Karaf 4.
> >
> > Thoughts ?
> > Guillaume Nodet
>
> --
> Daniel Kulp
> dkulp@apache.org <mailto:dkulp@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://coders.talend.com <
> http://coders.talend.com/
> >
>



-- 
Cheers,
Jon
---------------
Red Hat, Inc.
Email: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Camel in Action:
https://www.manning.com/books/camel-in-action-second-edition

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message