Hey guys, The Jakarta branch [1] just went into master, HUGE THANKS everyone for tremendous effort! Please note, it is still work in progress, the things to be done are tracked under [2], feel free to add more items or pick the existing ones. The master builds still have some tests failing, but those should be fixed shortly. With that, 3.6.x-fixes becomes the "mirror" of the master but for javax.* packages. Cherrypicking / backporting changes from master might be a bit more complicated (jakarta.* -> javax.*) but manageable.
One more thing, the pull requests against master and 3.6.x / 3.5.x are build using JDK-17 now (was JDK-11 before), this is due to the fact that master needs JDK-17, as it's Spring 6 / Spring Boot 3 JDK baseline. I have difficulties configuring Jenkins Maven builds + Github Pull Request builder per branch. It may be possible with pipeline, I will experiment with that. Please share any concerns, comments or feedback, it is highly appreciated. Thank you! [1] https://github.com/apache/cxf/pull/912 [2] https://issues.apache.org/jira/browse/CXF-8371 Best Regards, Andriy Redko COh> +1 from me. COh> Colm. COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma <mail2ji...@gmail.com> wrote: >> >> Hi Andriy, >> A good plan. I agree with all these changes and support versions. >> >> Thanks, >> Jim >> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko <drr...@gmail.com> wrote: >> >> > Hey folks, >> > >> > While the work on 4.x / Jakarta is slowly but steadily moving forward, it >> > is >> > time to think about next 3.x release line. As we discussed in this thread, >> > it >> > seems we agreed on 3.6.x to be next javax.* based release, with JDK-11 as >> > the >> > baseline. We have new Spring Boot 2.7.0 just released [1], along with tons >> > of other >> > related projects. I would like to propose to: >> > - branch off 3.6.x-fixes (from master) and work on upgrades (+ some new >> > features) >> > - as per @Jim suggestion, merge (very soon) Jakarta branch [2] into master >> > >> > From the support perspective, it means we would need to maintain 3.4.x for >> > some >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at some point). What do >> > you >> > think guys? Thank you! >> > >> > [1] https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now >> > [2] https://github.com/apache/cxf/pull/912 >> > >> > Best Regards, >> > Andriy Redko >> > >> > >> > JM> Hi Andriy, >> > JM> I took some time to look at the CXF java11 support and spring >> > decoupling >> > JM> last week. >> > JM> Here are some thoughts and initial work: >> > JM> 1) Use cross compile to support java11 . We can simply change >> > JM> <cxf.jdk.version> in pom.xml to 11. >> > JM> This will allow the maven compiler plugin to build cxf with java11. >> > JM> 2) We can look at creating some separate modules for Spring relevant >> > JM> code/configuration in the future. Ideally a small >> > JM> number of modules would be better and it will make it easy for users >> > to >> > JM> import spring relevant dependencies. >> > JM> Here is my initial work : >> > https://github.com/jimma/cxf/commits/spring >> > JM> <https://github.com/jimma/cxf/commits/spring>. This only touches >> > several >> > JM> cxf modules, I am not >> > JM> sure if this approach will get other blockers and issues. >> > >> > JM> Thanks, >> > JM> Jim >> > >> > >> > >> > JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <drr...@gmail.com> >> > wrote: >> > >> > >> 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 >> > >> >
