+1

By the way, isn't the plan on June per this blog
<https://camel.apache.org/blog/LTS-Release-Schedule/>?
>From my side, I( will try to get as many azurev12 components as possible
into 3.3 release.

Regards,
Omar

On Wed, Apr 15, 2020 at 8:11 AM Jean-Baptiste Onofre <j...@nanthrax.net>
wrote:

> +1
>
> I will work on camel-karat as well.
>
> Regards
> JB
>
> > Le 15 avr. 2020 à 07:28, Claus Ibsen <claus.ib...@gmail.com> a écrit :
> >
> > Hi
> >
> > Lets keep the momentum going and release a new 3.x version next month.
> > And lets aim for 3 weeks time. So if we can get Camel 3.3 released in
> > start of / mid May 2020, then that would be great.
> >
> > Here are some of the areas to work on and see if we can get
> > implemented and also the stuff already done.
> >
> > 1) Reflection free *DONE*
> > We have continued the work to make Camel use less reflections and have
> > now fixed the remainder bits in Rest DSL and Circuit Breakers.
> > And there were some data formats that wasnt entirely fixed either.
> >
> > 2) Reflection free custom POJOs *DONE*
> > We can now use @Configurer on custom POJOs and with our maven tool
> > generate source code to configure without reflection
> >
> > 3) JAXB free *DONE*
> > There were a few spots left to remove JAXB from the classpath when its
> > not needed. Now Rest DSL is also free when you do not use XML
> > bindings.
> > And also remove JAXB from maven pom etc.
> >
> > 4) Bugs reported about Camel 3.2 *DONE*
> > We have fixed the problems reported with Camel 3.2 such as install on
> > karaf, or the endpoint-dsl not support property placeholders.
> >
> > 5) Website improvements
> > The website keeps improving but this work is less dependent on the
> > Camel 3.3 release.
> >
> > 6) Lightweight CamelContext
> > gnodet will continue his experiment with this for really lightweight
> > and fast Camel for graalvm/quarkus.
> >
> > 7) doInit vs doStart
> > We should continue move and splitup initialization logic into early
> > phase when possible.
> >
> > 8) Move reifiers to separate module / move model out of runtime
> > If possible lets see if we can get more classes modularized so we can
> > for example avoid having model classes at runtime if not needed.
> >
> > 9) Look at if we can align auto configuration of components in SB vs
> camel-main
> >
> > And then the usual bunch of stuff with new components, bug fixes,
> > dependency upgrades and whatnot.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>

Reply via email to