camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonin Stefanutti <anto...@stefanutti.fr>
Subject Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Date Thu, 24 Mar 2016 08:28:47 GMT
Hi Claus,

Just in case for info, there is apparently a new BND Maven plugin [1] that is supposed to
alleviate some of the issues encountered with maven-bundle-plugin.

I haven’t tried it (nor am knowledgeable in the area) but that may be good to know at some
point for that piece of work.

[1]: http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html

Antonin

> On 24 Mar 2016, at 07:44, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> 
> Hi
> 
> m)
> Upgrade OSGi
> 
> We are using osgi 4.3.1 version which whatever OSGi version that is.
> But there is a OSGi 5.0 that newer Karaf containers uses.
> 
> But the big pain is upgrading maven-bundle-plugin. We are currently
> using an old 2.3.7. But the newer versions have their new sets of
> problems / fixes.
> 
> i have struggled with newer versions generating missing details in the
> manifest.mf files. For example camel-core did not export all its
> packages etc. A bit scary. But we do have a fair bit of maven
> properties and other osgi "magic" to make the build process build OSGi
> modules across all the 250 or so artifacts.
> 
> I pushed to a branch called osgi-trouble where you can see some of this problems
> https://github.com/apache/camel/commits/osgi-trouble
> 
> Using the latest 3.0.1 bundle plugin fails to build camel-core. It
> complains something about the osgi activator.
> 
> 
> 
> 
> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> Hi
>> 
>> So Camel 2.17 was the last release supporting Java 1.7.
>> The next Camel 2.18 is requiring Java 1.8.
>> 
>> Here is some thoughts of mine about this release up for discussion.
>> 
>> 
>> 
>> a)
>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>> 1.8 and Camel 3.0.
>> 
>> By that I mean the release should be a way of moving our existing
>> users from Java 1.7 and the current Camel APIs and the likes gradually
>> towards Java 1.8 and eventually Camel 3.0.
>> 
>> In other words we should not get carried away to change/break APIs and
>> whatnot just because Java 1.8 lambdas and functions.
>> 
>> There are too many current users that rely on the current Camel API
>> and we cannot go around change processor / expression / predicate /
>> aggregation strategy and other interfaces to be java 8 functional if
>> that means current code cannot compile. And certainly not adding
>> Optional<X> as return types all over.
>> 
>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>> changes that are Java 8 lambda / functional based. And as well changes
>> in the DSL to go with that.
>> 
>> There are some minor code changes needed to make the source compile as
>> source 1.8 to go in this Camel 2.18 let alone.
>> 
>> 
>> b)
>> Drop components that do not support and run on Java 1.8
>> And potentially remove some deprecated components
>> 
>> 
>> c)
>> Drop karaf 2.x.
>> And move to karaf 4.x for all our testing.
>> 
>> 
>> d)
>> Drop Jetty 8.x.
>> 
>> This also requires to upgrade at least two components that currently
>> rely on Jetty 8 to use Jetty 9.
>> 
>> 
>> e)
>> Upgrade to latest Jetty 9.
>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>> 
>> 
>> f)
>> Drop support for older versions of Spring. We have a number of
>> camel-test-spring3 etc modules that can be dropped. And maybe even
>> spring 4.0. as its also EOL.
>> 
>> 
>> g)
>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>> module. So camel-spring can use latest version of Spring safely. This
>> also makes it easier to deprecated spring-dm and remove it eventually.
>> The Karaf team is working on a sping -> blueprint layer so you can use
>> spring xml files but Karaf will "convert" that under the hood to
>> blueprint and run it as blueprint. When that is ready we no longer
>> need spring-dm.
>> 
>> 
>> h)
>> Continue adding components docs in the source, eg src/main/doc files.
>> So we eventually have as many/all of them. This is an ongoing effort,
>> as we need to do this for the EIPs and the other parts of the docs.
>> 
>> However I see this as a great step for a new documentation and
>> website, that IMHO is a big goal for Camel 3.0. To make the project
>> website fresh and modern. And make the documentation easier for end
>> users to use and view.
>> 
>> 
>> i)
>> Add camel-hysterix component and integrate camel's circuit breaker
>> into turbine/hysterix so you can see metrics from camel in the
>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>> 
>> 
>> j)
>> Split camel-cxf into modules so we can separate WS and RS and also
>> spring vs blueprint. Today its big ball of dependencies that is a bit
>> hard to slice and dice. Specially for MSA style with REST and you dont
>> want to add in a bunch of extra not needed JARs.
>> 
>> 
>> k)
>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>> 
>> 
>> l)
>> Timeline. This release do not need to have 6-8 months timeframe. We
>> could try to get this "stepping stone" release done sooner, so it can
>> be released during/shortly after summer.
>> 
>> There is plenty of "first work" that we must do with the java 8
>> upgrade and dropping older techs etc, that we have our hands full for
>> a while.
>> 
>> Doing a release with these changes allows our end users to migrate
>> along in a easy way, than a big bang - breaking apis - release would
>> do. And the latter would be more appropriate to be released as Camel
>> 3.0.
>> 
>> Then towards the end of this year, we can see where we are and plan
>> for a Camel 3.0 with a new website and documentation that such a
>> release deserve. For example if we release Camel 3.0 in start of 2017
>> then its also Camel's 10 year birthday year.
>> 
>> And doing such a release with a rewamped website with fresh looking
>> documentation and content, is what helps the project a lot.
>> 
>> The current website looks the same as it did when it was created:
>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>> 
>> PS: We surely also need a better "what is Camel" story on the front
>> page. Its still that very first one with all the tech jumble that was
>> initially created.
>> 
>> PPS: I would also love to see a new Camel logo. The current one is a
>> bit dull and boring.
>> 
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Mime
View raw message