+1 for this way, it's much easier. Thanks! Freeman
On Fri, Sep 9, 2022 at 3:55 PM Andriy Redko <drr...@gmail.com> wrote: > Hi Jim, > > It sounds easier, requiring less efforts, I agree. > Colm, Freeman, are you on board with this approach guys? > Thanks! > > Best Regards, > Andriy Redko > > JM> Hi Andriy, > JM> From what I looked at last time, it seems it's difficult to decouple > these > JM> osgi/karaf integration code from cxf core > JM> and create a new project to put it into a separate repository. IMO, we > can > JM> create a branch before we > JM> remove these integration codes, and later we can look at this branch to > JM> restore the osgi/integration code when > JM> osgi jakarta support is available. Your thoughts? > > JM> Thanks, > JM> Jim > > JM> On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko <drr...@gmail.com> wrote: > > >> Hey guys, > >> > >> Thanks a lot for bringing the clarity on possible timelines. @Jim, how > do > >> you want > >> to proceed with that? Do you think it is good idea to move off Apache > >> Karaf integration > >> into separate repository altogether (we discussed that a few times as > >> well)? Should we > >> preserve the OSGi-related hooks but replace them with "dummy" > >> implementation (like HTTP > >> transport for example)? @Colm, @Freeman what do you think? (assuming the > >> goal is to put > >> this chunk of codebase aside and bring it back when time comes). > >> > >> Thanks! > >> > >> Best Regards, > >> Andriy Redko > >> > >> > >> > 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 > >> > >> > >
