Le mer. 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. > We need to leverage those in camel-quarkus, I don't think it has been done yet. > > 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. > Yes, I have pushed a PR to add the lightweight context to camel-quarkus but without the split between init / start between static / runtime phases. This means there's no real gain yet. I've pushed this first PR because the split between init / start can be tricky for some components and I need to find a way to indicate that a given component does not support init at static time. > 7) doInit vs doStart > We should continue move and splitup initialization logic into early > phase when possible. > Yes, it's mostly in components now. The camel core services have been enhanced already. > > 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. > I don't think this is doable completely, however, the lightweight context basically allows to get rid of the model already and my experiments shows that GraalVM can dead code eliminate most of them, so I don't think we'll gain much more here. > > 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 > -- ------------------------ Guillaume Nodet
