Hi Antoine Yay sounds good. What do you fancy working with?
We got stuff around OSGi such as - upgrading the tests to be karaf 4.x based - drop karaf 2.x - upgrade to OSGi 5.0 Some easier ones would be in the platforms/karaf/features to make karaf 4 the default being used in the validation, currently its 2.x. And likewise in the tests/camel-itest-karaf. For non OSGi stuff then one of the most hard ones is to migrate two components to Jetty 9. I think its camel-cometd and camel-websocket. There is also an easier one to upgrade jetty 9.2 -> 9.3. And then there is also the component docs to create adoc files. Andrea knows how to do that, so he can tell the procedure. There is a way you can export from wiki and then manually need to do some adjustments. Then there is the splitup of camel-cxf into smaller components to separate it from ws/rs and spring/blueprint etc. And there is also Raul's branch with the change in the build system for lambda compilation that affects all OSGi. So it need rigorous OSGi testing before it can be merged. See other email in this @dev. And there is JIRA with the 2.18 tickets https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <anto...@toulme.name> wrote: > I’d like to help for this release. Looks like you got a good laundry list > already. Where can I help best in that list? > > >> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <claus.ib...@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
