Le mer. 11 août 2021 à 14:27, Andriy Redko <drr...@gmail.com> a écrit :
> Hey Jim, Romain, > > Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11 > baseline is good idea, we would > still be maintaining 3.4.x for a while, covering JDK-8 based deployments. > Regarding Jakarta, yes, I > certainly remember the discussion regarding the build time approach, > personally with time I came to the > conclusion that this is not the best option for at least 2 reasons: > - differences between source vs binary artifacts are very confusing > (source imports javax, > binary has jakarta, or vice versa), I think we all run into that from > time to time > Think maven shade plugin fixed that (and if you still find an issue it easier to fix it than handling 2 branches right?). > - Jakarta is the way to go, the mainstream should have first class support > This is compatible as explained. > > Just my 5 cents, but we certainly should consider this approach as well, > there are good points to > follow it, summarizing what we have at the moment: > > Option #1: > - 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, ...) > Think 4/5 should stay for user features changes (like making cxf-core very slim and jaxrs way lighter and less monolitic to quote one I have in mind since years). Moving its major with no impact on end users is always weird IMHO. > > Option #2: > - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline > - 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 > (Romain), or > adding a new maven module to transform cxf artifacts with jakarta > package name (Jim) +1 indeed ;) > > > Option #3: > - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline > - move master to 4.x to continue the work on supporting Jakarta 9.0+, > with JDK-11 as the minimal > required JDK version (Jetty 11, ...) > > Thank you! > > Best Regards, > Andriy Redko > > > JM> On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko <drr...@gmail.com> > wrote: > > >> 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). > > >> 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? > > > JM> For Jakarta EE9 support , the another option could be adding a new > maven > JM> module to transform cxf artifacts > JM> with jakarta package name. This transformed artifact can coexist with > the > JM> javax namespace with "jakarta" classifier, > JM> and we don't have to maintain two branches until Jakarta EE10 and > there are > JM> new features added. > > JM> Other projects like hibernate and jackson use this shade plugin or > Eclipse > JM> transformer to support jakarta ee9: > > JM> > https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100 > > JM> > https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.xml#L115 > > > > >> 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? > > >> 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 > >
