Hey guys, A bunch of good things have happened at the end of this year. The 3.5.0 out and we are in a good shape to kick off Jakarta support: the Spring 6 milestones and Spring Boot 3 snapshots are already available. There are tons of things to fix and address, I have created this draft pull request [1] with a first batch of changes and TODOs. Everyone should be able to push changes in there, if not - please let me know, I could give perms / move the branch to CXF Github repo. Hope in the next couple of months we get closer to fully embrace Jakarta.
On the not so good news side, Spring 6 has kept JDK-17 baseline. It does not play well with our original plan to stick to JDK-11 baseline for 4.x but I am not sure we have any choice here besides bumping the baseline as well. Happy Holidays guys! [1] https://github.com/apache/cxf/pull/888 JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy Redko <drr...@gmail.com> wrote: >> Hey Jim, >> No, we don't have a branch just yet, primarily because we depend on the >> few >> snapshots in 3.5.0/master. >> @Colm do you have an idea regarding xmlschema 2.3.0 release timelines? >> @Dan do you have an idea regarding neethi 3.2.0 release timelines? >> At worst, you could create a new branch for this feature, or submit a >> pull request against master which we should be able to re-target later >> against the right branch (should be easy). What do you think? JM> This is a good idea. I'll send a PR against the master, and later we can JM> decide the place to merge. JM> Thanks, Andriy. >> Best Regards, >> Andriy Redko >> JM> Thanks for more updates , Andriy. >> JM> Is there a place/workspace branch, I can send a PR for this change? >> JM> On Fri, Sep 3, 2021 at 9:20 PM Andriy Redko <drr...@gmail.com> wrote: >> >> Hey Jim, >> >> Thanks a lot for taking the lead on this one. Just want to chime in on a >> >> few points. Indeed, as >> >> per previous discussion in this thread, it seems like it make sense to >> >> provide only the subset >> >> of shaded modules with Jakarta namespace. Also, it was confirmed >> yesterday >> >> that Spring Framework >> >> 6 milestones will be available in November this year but the first >> >> snapshots will be out in late >> >> September / early October, looks pretty promising. One **unexpected** >> part >> >> of the announcement >> >> is JDK17 baseline for Spring Framework & Co, that could be a bummer but >> I >> >> have the feeling that >> >> it will be lowered to JDK11. Thank you. >> >> Best Regards, >> >> Andriy Redko >> >> JM> Good point, Romain. We need to look at what to do to make sure all >> >> JM> artifacts are included and transformed if this becomes a cxf module. >> >> JM> BTW, Spring 6 GA supports jakarta ee9 will come in Q4 2022 : >> >> JM> >> >> >> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 >> >> JM> On Fri, Sep 3, 2021 at 6:20 PM Romain Manni-Bucau < >> >> rmannibu...@gmail.com> >> >> JM> 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
