Hi Andriy, It looks like we still have to wait for the other dependency jakarta support available, like brave's new release to include this change : https://github.com/openzipkin/brave/pull/1344. Do you see any other dependencies that haven't been released yet except OSGI and Karaf ?
Thanks, Jim 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 >>>> >>> >> > >>>> >>> >> > >>>> >>> >>>> >>> >>>> >>>> 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 >>>> >>> >> > >>>> >>> >> > >>>> >>> >>>> >>> >>>> >>>>
