Hi Okay so work on being ready to cut the 3.3.0 release by weekend, or sooner if we are ready. I have updated JIRA and moved tickets to 3.4.0 but there are still around 20 ish tickets.
The CI build looks good, only the karaf tests are failing after upgrading to 2.5.x and the testcontainers that are using 2.5.x compatible images somehow fails with a weird error. I haven't been able to find out why, so anyone who love kafka are welcome to fight this. On Wed, Apr 15, 2020 at 7:28 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > > 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 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
