Hi This is really great to have you back and what an awesome work you have been doing. Its great with new set of eyes on the big chunk of camel-core.
We should definitly continue on this work for Camel 3 IMHO. First we should get Camel 2.23 out of the door, and then we can focus on Camel 3. For Camel 2.23 we should possibly aim for Spring Boot 2.1 so we have a latest release of Camel that is fully up to date with latest versions of that. That can give us calm time to then focus on Camel 3. I think in a few weeks time we will also get some time to start putting together some ideas for more high-level goals for Camel 3, than besides the work Guillaume have done so far, or what we have in JIRA with Camel 3.0. Myself will be traveling the next 3 weeks with less time online, but keep on rocking and being awesome in this community. On Wed, Oct 3, 2018 at 5:37 PM Guillaume Nodet <gno...@apache.org> wrote: > > Hey guys ! > It's been a long time I've been working actively on Camel, so I'm glad to > be back ! > I've spent the last few weeks working on a few things related to a possible > Camel 3.x branch, mainly: > * removing all deprecated stuff (or most of them) > * making camel-core more modular by extracting stuff out of it > Given those changes lead to incompatible changes, I've refactored my > changes on top of a change to version 3.0.0-SNAPSHOT. > I've uploaded the branch at > https://github.com/apache/camel/tree/sandbox/camel-3.x > > The first item is quite simple in principle, i.e. I've removed everything > that was flagged as @Deprecated. A lot of changes were more complicated > than just removing a few lines, and some of them were actually substantial. > > On top of that, I've worked on some JIRA already raised for 3.x and also a > few enhancements (like the ServiceSupport one, though there are still some > incoherences). > > One of my goal was to experiment on making camel-core more modular, which > I've worked on these past days. This requires moving some stuff from one > package to another to make packages more cohesive and be able to later > extract them. So o.a.c.util.* do not depend on a.o.c anymore, which means > some stuff has been moved to o.a.c.support and similar changes. Also, base > classes such as DefaultComponent, DefaultEndpoint and related have been > moved from o.a.c.impl to o.a.c.support. > I'll continue experimenting a bit on this modularization to ensure that > components can be built without relying on camel-core directly. > > Another thing I've experimented but not yet ported to that branch is to > isolate o.a.c.model from the actual processors. This is done by extracting > the code that translates the XxxDefinition into YyyProcessor into a > separate package. This should allow experimenting with stuff like > generating fluent xml/java dsls from the metadata. > > Just wanted to provide some feedback on my latest huge commit and make > things public. I'm planning to rebase on top of master regularly until the > community decides of the fate of this branch :-) > > Guillaume > > > -- > ------------------------ > Guillaume Nodet -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
