Le ven. 3 sept. 2021 à 11:30, Jim Ma <mail2ji...@gmail.com> a écrit :
> > > 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 ? > If not all artifacts are proposed with jakarta support it is an option otherwise it would need a build module to synchronize this submodule(s) to ensure none are forgotten - this is where I prefer the classifier approach even if it has this exclusion pitfalls - but cxf has it anyway due to its transitive dependencies so not worse IMHO ;). > > > > > > >> >> >>> 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 >>>>> >>>>> >>>>>
