Thanks for the update, Andiry. You already did a lot of work on third party jakarta support !
Just to understand the CXF Jakarta support work status, are these issues we can start without waiting for the dependency release ? https://issues.apache.org/jira/browse/CXF-8716 https://issues.apache.org/jira/browse/CXF-8717 https://issues.apache.org/jira/browse/CXF-8719 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 > >>>>> >>> >> > > >>>>> >>> >> > > >>>>> >>> > >>>>> >>> > >>>>> > >>>>> > >
