Le mer. 25 août 2021 à 13:39, Jim Ma <[email protected]> a écrit :
> > > On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <[email protected]> > wrote: > >> >> >> Le jeu. 19 août 2021 à 22:45, Andriy Redko <[email protected]> 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 ? > Not ready for cxf but looking at meecrowave-core pom you would have some idea. I just suspect pom deps need some refinement like with/without the client (it is useless with java 11 now and less and less desired AFAIK). > 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 <[email protected]> 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 <[email protected]> >>> 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 < >>> [email protected]> >>> >> >> 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/%[email protected]%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 >>> >>> >>>
