I accidentally clicked the send button, please ignore my previous email and look at this reply.
On Sat, Jan 29, 2022 at 7:58 PM Jim Ma <mail2ji...@gmail.com> wrote: > > > > On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <drr...@gmail.com> wrote: > >> 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. > > > From the JakartaEE9 release[1]and JakartaEE10 plan[2], it still needs to support JDK11. Jakarta Restful WebService 3.0/3.1 and Jakarta XML Web Services 3.0/3.1 apis are the specifications we need to implement in CXF, so we need to build, run and test implementation with JDK11. Just thinking this loud, is it possible that we make Spring plugable or really optional ? 4.x is the major release and it's the chance to refactor CXF code(like we move spring related source/test to separate module) to build/run/test without Spring with a maven profile. [1] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan [2] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan > >> >> >> 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 >> >>
