Thanks Jim, I will take a close look! Freeman
On Wed, Sep 21, 2022 at 4:02 AM Jim Ma <mail2ji...@gmail.com> wrote: > Hi All, > I tried to remove the osgi and karaf from CXF with this draft PR : > https://github.com/apache/cxf/pull/999 > <https://github.com/apache/cxf/pull/999>. > This mainly removed the osgi code,test, examples and dependency, but for > some class like SpringBus which deeply coupled with osgi: > > https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 > <https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142> > I added the comment "//uncomment this when osgi comes back" to mark these > commented lines for osgi. With the branch created before > this change is merged to main, I am sure this will make it easy to bring > the osgi and karaf back when the Jakarta support is ready in the future. > > Please help review this PR. If you have any comment or question, please > let me know. > > Thanks, > Jim > > > On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko <drr...@gmail.com> wrote: > >> Hi Jim, >> >> That is correct, I am working on >> https://issues.apache.org/jira/browse/CXF-8717 as part of >> Jetty 11 migration, the Atmosphere implementation seems to be fine. >> Thanks. >> >> Best Regards, >> Andriy Redko >> >> >> JM> Thanks for the update, Andiry. You already did a lot of work on third >> party >> JM> jakarta support ! >> >> JM> Just to understand the CXF Jakarta support work status, are these >> issues we >> JM> can start without waiting for the dependency release ? >> JM> https://issues.apache.org/jira/browse/CXF-8716 >> JM> https://issues.apache.org/jira/browse/CXF-8717 >> JM> https://issues.apache.org/jira/browse/CXF-8719 >> >> >> >> JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <drr...@gmail.com> wrote: >> >> >> Hi Jim, >> >> >> >> Yeah, we may need some time, I am also finalizing work on the Wiremock >> ( >> >> https://github.com/wiremock/wiremock/pull/1942), >> >> we use it in tests extensively. One of the largest efforts is >> migration to >> >> Jetty 11, I have started on that already but >> >> have difficulties with WebSockets migration, it needs rework and that >> is >> >> my focus at the moment. The Swagger 1.x we have >> >> to drop I believe, I don't see roadmap on Jakarta support there. >> >> >> >> Thanks! >> >> >> >> Best Regards, >> >> Andriy Redko >> >> >> >> JM> Hi Andriy, >> >> JM> It looks like we still have to wait for the other dependency >> jakarta >> >> JM> support available, like brave's new release to include this change >> : >> >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see any >> other >> >> JM> dependencies that haven't been released yet except OSGI and Karaf ? >> >> >> >> JM> Thanks, >> >> JM> Jim >> >> >> >> >> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> >> wrote: >> >> >> >> >> Thanks for the informative input, Freeman. >> >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a >> good >> >> >> chance to do this job. When OSGI/Karaf jakarta release is ready, >> >> >> We can look at bringing this back with more improvement and refactor >> >> work >> >> >> to make it loosely coupled with core code. >> >> >> >> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang <freeman.f...@gmail.com >> > >> >> >> wrote: >> >> >> >> >> >>> Hi Jim, >> >> >>> >> >> >>> Sorry for the late reply, just back from vacation. >> >> >>> >> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec >> which >> >> will >> >> >>> support Jakarta namespace is in progress and isn't released >> yet(and I >> >> don't >> >> >>> think there is a concrete release date for OSGi R9 spec in the new >> >> future). >> >> >>> Before OSGi R9 spec gets released and adopted by OSGi >> implementations >> >> like >> >> >>> Felix/Equinox, I don't think there is much we can do in CXF or >> even in >> >> >>> Karaf about this part. >> >> >>> >> >> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf >> bit >> >> >>> seems the only option we have so far, and I'm +1 for this way >> >> now(Since we >> >> >>> don't know how long we need to wait for the proper OSGi spec >> released >> >> and >> >> >>> upstream projects can support it). >> >> >>> >> >> >>> Just my 2 cents. >> >> >>> Best Regards >> >> >>> Freeman >> >> >>> >> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> >> wrote: >> >> >>> >> >> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with >> Freeman >> >> >>>> about this topic several months ago and got to know >> >> >>>> there won't be Jakarta namespace support work in the future. I >> don't >> >> >>>> know if this has changed. >> >> >>>> Freeman, do you have some update on this ? >> >> >>>> >> >> >>>> >> >> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com> >> >> wrote: >> >> >>>> >> >> >>>>> Hey Jim, >> >> >>>>> >> >> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are >> real >> >> >>>>> blockers. For Swagger 1.x, we could >> >> >>>>> go ahead and drop the support altogether, this is quite isolated >> >> >>>>> feature. OSGi and Karaf are not, those >> >> >>>>> penetrated very deep into core. What worries me, if we drop >> >> everything >> >> >>>>> OSGi/Karaf related from 4.0.0, we >> >> >>>>> may need to bring it back some time in the future (with OSGi R9 >> [4] >> >> fe) >> >> >>>>> and that is going to be quite >> >> >>>>> difficult. From other side, this is probably the only option to >> have >> >> >>>>> 4.0.0 milestone out (we excluded some >> >> >>>>> modules from the build right now but that is more like a >> temporary >> >> hack >> >> >>>>> which we should not release upon, >> >> >>>>> even alphas). What do you think guys? >> >> >>>>> >> >> >>>>> Best Regards, >> >> >>>>> Andriy Redko >> >> >>>>> >> >> >>>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >> >> >>>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >> >> >>>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >> >> >>>>> [4] https://github.com/osgi/osgi/milestone/5 >> >> >>>>> >> >> >>>>> JM> After we merged the jakarta branch to default branch main >> branch, >> >> >>>>> do we >> >> >>>>> JM> need to create some >> >> >>>>> JM> plan to do a future 4.x release? >> >> >>>>> >> >> >>>>> JM> There are a couple of to-do things under >> >> >>>>> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >> >> >>>>> JM> and for some of them we can't do more things because of the >> >> jakarta >> >> >>>>> JM> dependency missing. It seems that some of the dependencies >> won't >> >> >>>>> JM> have the jakarta namespace artifact released in the near >> future. >> >> >>>>> Should we >> >> >>>>> JM> have some milestone/alpha release >> >> >>>>> JM> before all these dependencies are available ? And if we >> want to >> >> do >> >> >>>>> a >> >> >>>>> JM> milestone release, what do you think we should have in >> >> >>>>> JM> this 4.0.0-M1 release ? >> >> >>>>> >> >> >>>>> >> >> >>>>> JM> Thanks, >> >> >>>>> JM> Jim >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma < >> mail2ji...@gmail.com> >> >> >>>>> wrote: >> >> >>>>> >> >> >>>>> >> Thanks Andriy too for driving this and moving forward ! >> >> >>>>> >> >> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko < >> drr...@gmail.com> >> >> >>>>> wrote: >> >> >>>>> >> >> >> >>>>> >>> 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 >> >> >>>>> >>> >> > >> >> >>>>> >>> >> > >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >> >> >>>>> >> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> >> wrote: >> >> >> >> >> Thanks for the informative input, Freeman. >> >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a >> good >> >> >> chance to do this job. When OSGI/Karaf jakarta release is ready, >> >> >> We can look at bringing this back with more improvement and refactor >> >> work >> >> >> to make it loosely coupled with core code. >> >> >> >> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang <freeman.f...@gmail.com >> > >> >> >> wrote: >> >> >> >> >> >>> Hi Jim, >> >> >>> >> >> >>> Sorry for the late reply, just back from vacation. >> >> >>> >> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec >> which >> >> will >> >> >>> support Jakarta namespace is in progress and isn't released >> yet(and I >> >> don't >> >> >>> think there is a concrete release date for OSGi R9 spec in the new >> >> future). >> >> >>> Before OSGi R9 spec gets released and adopted by OSGi >> implementations >> >> like >> >> >>> Felix/Equinox, I don't think there is much we can do in CXF or >> even in >> >> >>> Karaf about this part. >> >> >>> >> >> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf >> bit >> >> >>> seems the only option we have so far, and I'm +1 for this way >> >> now(Since we >> >> >>> don't know how long we need to wait for the proper OSGi spec >> released >> >> and >> >> >>> upstream projects can support it). >> >> >>> >> >> >>> Just my 2 cents. >> >> >>> Best Regards >> >> >>> Freeman >> >> >>> >> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> >> wrote: >> >> >>> >> >> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with >> Freeman >> >> >>>> about this topic several months ago and got to know >> >> >>>> there won't be Jakarta namespace support work in the future. I >> don't >> >> >>>> know if this has changed. >> >> >>>> Freeman, do you have some update on this ? >> >> >>>> >> >> >>>> >> >> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com> >> >> wrote: >> >> >>>> >> >> >>>>> Hey Jim, >> >> >>>>> >> >> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are >> real >> >> >>>>> blockers. For Swagger 1.x, we could >> >> >>>>> go ahead and drop the support altogether, this is quite isolated >> >> >>>>> feature. OSGi and Karaf are not, those >> >> >>>>> penetrated very deep into core. What worries me, if we drop >> >> everything >> >> >>>>> OSGi/Karaf related from 4.0.0, we >> >> >>>>> may need to bring it back some time in the future (with OSGi R9 >> [4] >> >> fe) >> >> >>>>> and that is going to be quite >> >> >>>>> difficult. From other side, this is probably the only option to >> have >> >> >>>>> 4.0.0 milestone out (we excluded some >> >> >>>>> modules from the build right now but that is more like a >> temporary >> >> hack >> >> >>>>> which we should not release upon, >> >> >>>>> even alphas). What do you think guys? >> >> >>>>> >> >> >>>>> Best Regards, >> >> >>>>> Andriy Redko >> >> >>>>> >> >> >>>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >> >> >>>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >> >> >>>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >> >> >>>>> [4] https://github.com/osgi/osgi/milestone/5 >> >> >>>>> >> >> >>>>> JM> After we merged the jakarta branch to default branch main >> branch, >> >> >>>>> do we >> >> >>>>> JM> need to create some >> >> >>>>> JM> plan to do a future 4.x release? >> >> >>>>> >> >> >>>>> JM> There are a couple of to-do things under >> >> >>>>> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >> >> >>>>> JM> and for some of them we can't do more things because of the >> >> jakarta >> >> >>>>> JM> dependency missing. It seems that some of the dependencies >> won't >> >> >>>>> JM> have the jakarta namespace artifact released in the near >> future. >> >> >>>>> Should we >> >> >>>>> JM> have some milestone/alpha release >> >> >>>>> JM> before all these dependencies are available ? And if we >> want to >> >> do >> >> >>>>> a >> >> >>>>> JM> milestone release, what do you think we should have in >> >> >>>>> JM> this 4.0.0-M1 release ? >> >> >>>>> >> >> >>>>> >> >> >>>>> JM> Thanks, >> >> >>>>> JM> Jim >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma < >> mail2ji...@gmail.com> >> >> >>>>> wrote: >> >> >>>>> >> >> >>>>> >> Thanks Andriy too for driving this and moving forward ! >> >> >>>>> >> >> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko < >> drr...@gmail.com> >> >> >>>>> wrote: >> >> >>>>> >> >> >> >>>>> >>> 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 >> >> >>>>> >>> >> > >> >> >>>>> >>> >> > >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >> >> >>>>> >> >> >> >> >> >>
