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
