On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> > > Le jeu. 19 août 2021 à 22:45, Andriy Redko <drr...@gmail.com> a écrit : > >> Hi Romain, >> >> Sorry for the delayed response. I have been thinking about your (and Jim) >> suggestions >> and came to surprising conclusion: do we actually need to officially >> release anything >> to shade/overwrite javax <-> jakarta? Generally, we could shade Spring >> or/and any other >> dependency but we would certainly not bundle it as part of CXF >> distribution (I hope you >> would agree), so not really useful unless we publish them. As such, >> probably the best >> interim solution is to document what it takes to shade CXF (javax <-> >> jakarta) and let >> the end users (application/service developers) use that when needed? In >> this case >> basically CXF, Spring, Geronimo, Swagger, ... would follow the same >> shading rules. At >> least, we could start with that (documenting the shading process) and >> likely get some >> early feedback while working on full-fledged support? WDYT? >> > > > This is what is done and makes it hard for nothing to maintain/fix - dont > even look at tomee solution for shading please ;) - IMHO. > Being said it costs nothing to cxf to produce jakarta jars, that it makes > it ee 9 compliant and more consistent for all but spring usage (ee > integrators, plain tomcat 10 users etc...), I think it is worth doing it, > at minimum. > At least a jakarta jaxrs (over jakarta servlet) bundle would be a good > progress, not sure jaxws and other parts would be helpful since they tend > to be in maintainance mode from what I saw. > So IMHO the best is a shade/relocation in the parent to deliver a jakarta > artifact for all module + a few jakarta bom. But if too much - which I can > see/hear - a jakarta jaxrs bundle would work too short term. > I agree to start with something to preview and collect more ideas to support ee9. It's good to have a branch to really start something for this topic. @Romain, do you have a prototype with shading or other tools for a jakarta jaxrs bundle or just some basic idea that we can have a look at ? Thanks, Jim > > >> Thank you. >> >> Best Regards, >> Andriy Redko >> >> >> RMB> I'm not sure I see why you need spring to start this work. The >> expected is >> RMB> there already so spring module can still rely on javax, be made >> jakarta >> RMB> friendly using shade plugin or alike and that's it until a spring >> native >> RMB> integration is there. >> RMB> Worse case cxf-spring will not be usable with jakarta - which still >> enabled >> RMB> all other usages, best case if spring makes the transition smooth is >> that >> RMB> it will work smoothly without more investment than for the rest of >> the >> RMB> build. >> RMB> The pro of that options is that it will reduce the number of >> unofficial cxf >> RMB> relocations sooner IMHO. >> >> RMB> Romain Manni-Bucau >> RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> RMB> <https://rmannibucau.metawerx.net/> | Old Blog >> RMB> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> RMB> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > >> >> >> RMB> 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 >> >> >>
