Hi, I don't have strong views either way, but it seems like the majority favour having one more release of CXF with JDK 8 support. Andriy, when do you anticipate we could release CXF 3.5.0 by? I need to release new major versions of Santuario + WSS4J first, but there is not a huge amount of work involved. I would also like to drop CXF 3.3.x at the same time to reduce the maintenance burden on us.
Colm. On Tue, Aug 17, 2021 at 6:39 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > I'm not sure I see why you need spring to start this work. The expected is > there already so spring module can still rely on javax, be made jakarta > friendly using shade plugin or alike and that's it until a spring native > integration is there. > Worse case cxf-spring will not be usable with jakarta - which still enabled > all other usages, best case if spring makes the transition smooth is that > it will work smoothly without more investment than for the rest of the > build. > The pro of that options is that it will reduce the number of unofficial cxf > relocations sooner IMHO. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 16 août 2021 à 23:40, Andriy Redko <drr...@gmail.com> a écrit : > > > Hi Jim, > > > > I will try to answer your questions, other guys will definitely share more > > thoughts, please see mine inlined. > > > > >> What's the task for JDK-17 LTS preparation ? Do we need to support > > build 3.5.0 with JDK-17 ? > > > > Build + All tests are green. > > Apache Karaf 4.3.3 will support JDK17 so our OSGi test suites will pass. > > Besides that, there is still some work to do [1] but at least we have > > workarounds. > > > > >> For Jakarta ee9 support branch 4.x with source code change to support > > jakarta namespace , we have to wait for spring and other > > >> third party dependencies jakarta ee9 ready. Now we don't know when > > these dependencies are all ready and we can start this work. > > > > This is correct, the earliest we could expect something is Q4/2021 (fe > > Spring). > > > > >> Given there is no features added in Jakarta ee 9.1 besides the > > namespace change, we can provide the jakarta calssfier maven artifacts > > >> and binary release in 3.6.x or 4.x with transformation or other better > > approach will be enough.We provide jakarta ee9 support early, > > >> then we can get more feedback on this topic. > > > > It is definitely the option we have among others to discuss. I have no > > doubts that everyone has rough idea of the pros and cons > > each option has, as the team we are trying to pick the best path forward. > > Jakarta EE 10 is coming in Q1/2022 [2], we should keep it > > in mind as well. > > > > Thank you! > > > > [1] https://issues.apache.org/jira/browse/CXF-8407 > > [2] > > https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan > > > > > > Best Regards, > > Andriy Redko > > > > JM> On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko <drr...@gmail.com> wrote: > > > > >> 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 > > >> - Jakarta is the way to go, the mainstream should have first class > > support > > > > >> 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, ...) > > > > > > JM> What's the task for JDK-17 LTS preparation ? Do we need to support > > build > > JM> 3.5.0 with JDK-17 ? > > > > JM> For Jakarta ee9 support branch 4.x with source code change to support > > JM> jakarta namespace , we have to wait for spring and other > > JM> third party dependencies jakarta ee9 ready. Now we don't know when > > these > > JM> dependencies are all ready and we can start this work. > > > > JM> Given there is no features added in Jakarta ee 9.1 besides the > > namespace > > JM> change, we can provide the jakarta calssfier maven artifacts and binary > > JM> release in 3.6.x or 4.x with transformation or other better approach > > will > > JM> be enough.We provide jakarta ee9 support early, then we can get more > > JM> feedback on this topic. > > > > > > > > > > >> 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) > > > > >> 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 > > > >
