On 3/24/16 3:55 PM, Claus Ibsen wrote:
On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak
<krzys.sobkow...@gmail.com> wrote:
Hi
I'm not sure how the Camel Core actually looks like (especially the quality and
the ability to refactor or make more
complicated changes) but I had occasion to talk with some people using Camel
and trying to fix some issues (and
even saw some discussion in net about the state of Core) who think, the Core
became very complicated over the
years and it would be very difficult to make big changes in it. I think, it's
normal that the software which is developed
a long time can have code which is no more used or should be refactored.
I think, the way to Camel 3 should also include the renovation of the Core (if
really necessary) or even rewriting and
making it more asynchronous, e.g. using rx.java (the later can be eventually
part of Camel 4 roadmap if too dangerous
for Camel 3).
No this should not be the goal of Camel 3 IMHO. This is too disruptive
and would take too much effort and time away from other tasks. The
most important is to have a modern website, documentation and getting
started guides, examples and so on. So people can get onboard Camel.
+1
The renovation of the core is to cleanup all the deprecated stuff and
we will take a 2nd look after the 2.17 release to identify more stuff
to mark for deprecation in 2.18 and removal for 3.0.
+1
Yes for Camel 4 a new reactive/modern core could be on the agenda. And
then the time gap between Camel 3 and 4 do not have to be 6 years. For
example Spring is not reactive yet, but they are going there in Spring
5.x [1]. So when reactive becomes more main stream (with help from
Spring) and useable for the average developers then its likely also
interest for Camel users. Remember Camel users are no the "netflix
developers". Its use by every day developers. And we have a huge
community which we should not throw under the bus with risky moves.
Agreed. Our users are Enterprise developers that deploying software for
5-30 years. Having Camel a Camel 3.x with these goals provides a ton of
value to a user base that is large and mostly silent in these conversations.
People who want to look at reactive frameworks today can take a look
at vert.x, akka (problem a bit bad due Scala, but I think the company
behind them are moving to Java). For vert.x then their next release
will have a vertx-camel component out of the box.
There has been a camel-rx component for several years now, but nobody
has shown interest in it. Nor is people screaming in this community
about reactive libraries. In fact people rely on Camel being "not in
the forefront"
[1] - https://spring.io/blog/2015/12/03/spring-framework-5-0-roadmap-update
My 2 cents, but I think, we have here many people who are Camel experts and can
say more, whether it makes sense.
Kindly regards
Krzysztof
On 23.03.2016 11:07, Claus Ibsen 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.
--
Krzysztof Sobkowiak (@ksobkowiak)
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
