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 > >> >>>>> >>> >> > > >> >>>>> >>> >> > > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> > >> >>>>> > >> > >> > >
