Good point, Romain. We need to look at what to do to make sure all artifacts are included and transformed if this becomes a cxf module.
BTW, Spring 6 GA supports jakarta ee9 will come in Q4 2022 : https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 On Fri, Sep 3, 2021 at 6:20 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > > > 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 >>>>>> >>>>>> >>>>>>
