Hey Jim, AFAIR this particular topic has popped up several times, a few issues exist [1] and @Christian even did the POC several years ago [2] in attempt to remove some of the hard Spring dependencies (I don't know the outcomes to be fair but I suspect it turned out to be much more difficult than anticipated).
The suggestion I have in mind is to keep JDK-17 baseline **for now** and continue working on addressing the blockers (there too many at this point). Once we get to the state when the Jakarta branch is at least buildable / deployable, we could reassess the Spring coupling. I am just afraid doing everything at once would introduce instability in codebase and slow down everyone on either of these efforts. Not sure if you agree but in any case I am definitely +1 for reducing the scope of dependencies on Spring, even in 3.4.x / 3.5.x release lines. Thank you. [1] https://issues.apache.org/jira/browse/CXF-5477 [2] https://github.com/apache/cxf/tree/poc-remove-spring-bp Best Regards, Andriy Redko JM> I accidentally clicked the send button, please ignore my previous email JM> and look at this reply. JM> 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. JM> From the JakartaEE9 release[1]and JakartaEE10 plan[2], it still needs to JM> support JDK11. Jakarta Restful WebService 3.0/3.1 and Jakarta XML Web JM> Services 3.0/3.1 JM> apis are the specifications we need to implement in CXF, so we need to JM> build, run and test implementation with JDK11. JM> Just thinking this loud, is it possible that we make Spring plugable or JM> really optional ? 4.x is the major release and it's the chance JM> to refactor CXF code(like we move spring related source/test to separate JM> module) to build/run/test without Spring with a maven profile. JM> [1] JM> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan JM> [2] JM> 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
