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