You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Guillaume Nodet <gn...@apache.org> on 2018/10/03 15:36:46 UTC
[HEADS UP] Camel 3.x branch
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
Re: [HEADS UP] Camel 3.x branch
Posted by Onder SEZGIN <on...@gmail.com>.
Great start. Thanks...
On Thu, Oct 4, 2018 at 11:58 AM Luca Burgazzoli <lb...@gmail.com>
wrote:
> Amazing job Guillaume and welcome back !
>
> ---
> Luca Burgazzoli
>
> On Thu, Oct 4, 2018 at 10:38 AM Nicola Ferraro <ni...@gmail.com>
> wrote:
> >
> > That's really nice!
> > Working on Camel 3 is something we've deferred for a long time and the
> kind
> > of refactoring you've been doing is the right way to start IMO.
> >
> > Great job!
> >
> > On Thu, Oct 4, 2018 at 9:29 AM Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> > > 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 <gn...@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
> > >
>
Re: [HEADS UP] Camel 3.x branch
Posted by Luca Burgazzoli <lb...@gmail.com>.
Amazing job Guillaume and welcome back !
---
Luca Burgazzoli
On Thu, Oct 4, 2018 at 10:38 AM Nicola Ferraro <ni...@gmail.com> wrote:
>
> That's really nice!
> Working on Camel 3 is something we've deferred for a long time and the kind
> of refactoring you've been doing is the right way to start IMO.
>
> Great job!
>
> On Thu, Oct 4, 2018 at 9:29 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > 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 <gn...@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
> >
Re: [HEADS UP] Camel 3.x branch
Posted by Nicola Ferraro <ni...@gmail.com>.
That's really nice!
Working on Camel 3 is something we've deferred for a long time and the kind
of refactoring you've been doing is the right way to start IMO.
Great job!
On Thu, Oct 4, 2018 at 9:29 AM Claus Ibsen <cl...@gmail.com> wrote:
> 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 <gn...@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
>
Re: [HEADS UP] Camel 3.x branch
Posted by Claus Ibsen <cl...@gmail.com>.
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 <gn...@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
Re: [HEADS UP] Camel 3.x branch
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Awesome !
Thanks ! I have some WIP around camel on karaf as well.
Regards
JB
Le 4 oct. 2018 à 08:55, à 08:55, Andrea Cosentino <an...@yahoo.com.invalid> a écrit:
>Hey Guillaume, Thanks a lot! This is a wonderful start for Camel 3.x
>work!
>
>Many thanks! I'll take a look at the branch!
>
>
>
>--
>Andrea Cosentino
>----------------------------------
>Apache Camel PMC Chair
>Apache Karaf Committer
>Apache Servicemix PMC Member
>Email: ancosen1985@yahoo.com
>Twitter: @oscerd2
>Github: oscerd
>
>
>
>
>
>
>On Wednesday, October 3, 2018, 5:37:00 PM GMT+2, Guillaume Nodet
><gn...@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
Re: [HEADS UP] Camel 3.x branch
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
Hey Guillaume, Thanks a lot! This is a wonderful start for Camel 3.x work!
Many thanks! I'll take a look at the branch!
--
Andrea Cosentino
----------------------------------
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, October 3, 2018, 5:37:00 PM GMT+2, Guillaume Nodet <gn...@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
Re: [HEADS UP] Camel 3.x branch
Posted by Guillaume Nodet <gn...@apache.org>.
I've just pushed an updated branch further modularize camel-core.
The next step on my plan to continue working on isolating the model /
builders and the components / language from the core implementation.
Le mer. 3 oct. 2018 à 17:36, Guillaume Nodet <gn...@apache.org> a écrit :
> 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
>
>
--
------------------------
Guillaume Nodet