On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> > > Le mer. 25 août 2021 à 13:39, Jim Ma <mail2ji...@gmail.com> a écrit : > >> >> >> 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 ? >> > > > 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). > @Romain Manni-Bucau <rmannibu...@gmail.com> Thanks for the update. I looked at the meecrowave-core pom and understood how it transforms package names with the shade plugin. Both shade plugin or eclipse transformer tool works for this purpose . I created one prototype project which pulls in cxf dependencies, transforms to jakarta namespace and installs to local maven repository : https://github.com/jimma/cxf-ee9-transformer This doesn't need more effort and no need the code/dependency change which breaks/mixes with javax support codebase. It can be simply added with another maven module in cxf repo to produce transformed jakata cxf artifacts or binary distribution. Your thoughts ? > > >> 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 >>>> >>>> >>>>
