Hi Andriy, commented inline
Le mer. 11 août 2021 à 04:05, Andriy Redko <drr...@gmail.com> a écrit : > Hey guys, > > I would like to initiate (or better to say, resume) the discussion > regarding CXF 3.5.x and beyond. > The 3.5.x has been in the making for quite a while but has not seen any > releases yet. As far as > I know, we have only pending upgrade to Apache Karaf 4.3.3 (on SNAPSHOT > now) so be ready to meet > JDK 17 LTS next month. I think this is a good opportunity to release 3.5.0 > but certainly looking > for ideas and opinions here. Importantly, I think for 3.5.x the JDK-8 > should be supported as the minimal > required JDK version (just an opinion since JDK-8 is still very widely > used). That's true but it is also true no app using java 8 will be created anymore and no existing app needs a minor upgrade (just security patches) so java 11 can be the minimal requirement there too. > > > On the other side, many libraries (Jetty, wss4j, ...) are bumping the > baseline to JDK-11. The work > @Colm is doing to update to OpenSaml 4.x [1] is a good argument to have > the JDK-11+ release line. Should > we have a dedicated 3.6.x or 4.x.x branch(es) for that? > > Last but not least, Jakarta 9.0+ support. Last year we briefly talked > about it [2], at this moment it > looks like having dedicated release line (4.x/5.x) with Jakarta artifacts > is beneficial in long term. > Large chunk [3] of work has been already done in this direction. The > Spring 6 milestones with Jakarta > support are expected to land in Q4/2021 [4] but I am not sure what plans > Apache Karaf team has, @Freeman > do you have any insights? > >From my experience this requires some serious effort while a proper shading + bom setup avoids that completely and when API will evolve it can fully be maintained using org.apache.cxf.javaxcompat package for new API or alike (worse case you can rewrite part of the jakarta code for javax) so long story short master should be jakarta and javax handled with a build configuration IMHO until you can do the backport (manually since it is not the same packages) and systematically with a double release and doc each time. > > To summarize briefly: > - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline > - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK > version (Jetty 10, ...) > - branch off 5.x (4.x?) to continue the work on supporting Jakarta 9.0+, > with JDK-11 as the minimal > required JDK version (Jetty 11, ...) > > I think it is very clear that maintaining JavaEE + JDK8 / JavaEE + JDK11 / > Jakarta + JDK11 would consume > much more time from the team, but I am not sure we have other options if > we aim to evolve and keep CXF > up to date. Any thought, ideas, comments, suggestions guys? So my proposal would be: 1. min java version: 11 2. handle javax by a build setup (with api validation at build time to avoid regressions) and use jakarta package as main api in the project Hope it makes sense > > > Thank you! > > [1] https://github.com/apache/cxf/tree/opensaml4 > [2] > http://mail-archives.apache.org/mod_mbox/cxf-dev/202012.mbox/%3c1503263798.20201226124...@gmail.com%3E > [3] https://github.com/apache/cxf/pull/737 > [4] > https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960 > > Best Regards, > Andriy Redko > >
