Hey Colm, All skipped projects are listed here [1], the test cases (for now) don't have JIRAs but will be fixed at some point (hopefully - very soon), I am not sure we need separate tickets for that since we don't silence/ignore them. Thanks!
[1] https://issues.apache.org/jira/browse/CXF-8724 Best Regards, Andriy Redko COh> Hi, COh> No objection from me either. Apart from OSGi, could we make sure that COh> all the gaps are recorded in JIRA? COh> * Test failures in cxf-rt-mp-client - COh> https://issues.apache.org/jira/browse/CXF-8758 COh> * Test failures in COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket COh> related) - https://issues.apache.org/jira/browse/CXF-8717 COh> * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is COh> failing in the jms transport systests - JIRA? COh> * ./systests/container-integration/grizzly skipped - COh> https://issues.apache.org/jira/browse/CXF-8716 COh> * jaxrs systests skipped - JIRA? COh> * systests/wsdl_maven/codegen skipped - JIRA? COh> * maven-plugins/wadl2java-plugin - JIRA? COh> * maven-plugins/java2swagger-plugin - JIRA? COh> Colm. COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <drr...@gmail.com> wrote: >> >> Hi Jim, >> >> No objections from my side, thank you. >> >> Best Regards, >> Andriy Redko >> >> On Tue, Sep 27, 2022, 9:31 PM Jim Ma <mail2ji...@gmail.com> wrote: >>> >>> Hi all, >>> If there is no objection, I will create a branch "osgi-pre-removal-v4.0" to >>> record the changes before the osgi and karaf removal, then >>> merge the this PR https://github.com/apache/cxf/pull/999 to the main branch. >>> >>> Thanks, >>> Jim >>> >>> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko <drr...@gmail.com> wrote: >>>> >>>> This is great, thanks Jim, I will also take a look shortly. Thanks! >>>> >>>> Best Regards, >>>> Andriy Redko >>>> >>>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma <mail2ji...@gmail.com> wrote: >>>>> >>>>> Hi All, >>>>> I tried to remove the osgi and karaf from CXF with this draft PR : >>>>> https://github.com/apache/cxf/pull/999. >>>>> This mainly removed the osgi code,test, examples and dependency, but for >>>>> some class like SpringBus which deeply coupled with osgi: >>>>> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 >>>>> I added the comment "//uncomment this when osgi comes back" to mark these >>>>> commented lines for osgi. With the branch created before >>>>> this change is merged to main, I am sure this will make it easy to bring >>>>> the osgi and karaf back when the Jakarta support is ready in the future. >>>>> >>>>> Please help review this PR. If you have any comment or question, please >>>>> let me know. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >>>>> On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko <drr...@gmail.com> wrote: >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> That is correct, I am working on >>>>>> https://issues.apache.org/jira/browse/CXF-8717 as part of >>>>>> Jetty 11 migration, the Atmosphere implementation seems to be fine. >>>>>> Thanks. >>>>>> >>>>>> Best Regards, >>>>>> Andriy Redko >>>>>> >>>>>> >>>>>> JM> Thanks for the update, Andiry. You already did a lot of work on >>>>>> third party >>>>>> JM> jakarta support ! >>>>>> >>>>>> JM> Just to understand the CXF Jakarta support work status, are these >>>>>> issues we >>>>>> JM> can start without waiting for the dependency release ? >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8716 >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8717 >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8719 >>>>>> >>>>>> >>>>>> >>>>>> JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <drr...@gmail.com> wrote: >>>>>> >>>>>> >> Hi Jim, >>>>>> >> >>>>>> >> Yeah, we may need some time, I am also finalizing work on the >>>>>> >> Wiremock ( >>>>>> >> https://github.com/wiremock/wiremock/pull/1942), >>>>>> >> we use it in tests extensively. One of the largest efforts is >>>>>> >> migration to >>>>>> >> Jetty 11, I have started on that already but >>>>>> >> have difficulties with WebSockets migration, it needs rework and that >>>>>> >> is >>>>>> >> my focus at the moment. The Swagger 1.x we have >>>>>> >> to drop I believe, I don't see roadmap on Jakarta support there. >>>>>> >> >>>>>> >> Thanks! >>>>>> >> >>>>>> >> Best Regards, >>>>>> >> Andriy Redko >>>>>> >> >>>>>> >> JM> Hi Andriy, >>>>>> >> JM> It looks like we still have to wait for the other dependency >>>>>> >> jakarta >>>>>> >> JM> support available, like brave's new release to include this >>>>>> >> change : >>>>>> >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see any >>>>>> >> other >>>>>> >> JM> dependencies that haven't been released yet except OSGI and Karaf >>>>>> >> ? >>>>>> >> >>>>>> >> JM> Thanks, >>>>>> >> JM> Jim >>>>>> >> >>>>>> >> >>>>>> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> >>>>>> >> wrote: >>>>>> >> >>>>>> >> >> Thanks for the informative input, Freeman. >>>>>> >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a >>>>>> >> >> good >>>>>> >> >> chance to do this job. When OSGI/Karaf jakarta release is ready, >>>>>> >> >> We can look at bringing this back with more improvement and >>>>>> >> >> refactor >>>>>> >> work >>>>>> >> >> to make it loosely coupled with core code. >>>>>> >> >> >>>>>> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >>>>>> >> >> <freeman.f...@gmail.com> >>>>>> >> >> wrote: >>>>>> >> >> >>>>>> >> >>> Hi Jim, >>>>>> >> >>> >>>>>> >> >>> Sorry for the late reply, just back from vacation. >>>>>> >> >>> >>>>>> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec >>>>>> >> >>> which >>>>>> >> will >>>>>> >> >>> support Jakarta namespace is in progress and isn't released >>>>>> >> >>> yet(and I >>>>>> >> don't >>>>>> >> >>> think there is a concrete release date for OSGi R9 spec in the new >>>>>> >> future). >>>>>> >> >>> Before OSGi R9 spec gets released and adopted by OSGi >>>>>> >> >>> implementations >>>>>> >> like >>>>>> >> >>> Felix/Equinox, I don't think there is much we can do in CXF or >>>>>> >> >>> even in >>>>>> >> >>> Karaf about this part. >>>>>> >> >>> >>>>>> >> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf >>>>>> >> >>> bit >>>>>> >> >>> seems the only option we have so far, and I'm +1 for this way >>>>>> >> now(Since we >>>>>> >> >>> don't know how long we need to wait for the proper OSGi spec >>>>>> >> >>> released >>>>>> >> and >>>>>> >> >>> upstream projects can support it). >>>>>> >> >>> >>>>>> >> >>> Just my 2 cents. >>>>>> >> >>> Best Regards >>>>>> >> >>> Freeman >>>>>> >> >>> >>>>>> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> >>>>>> >> >>> wrote: >>>>>> >> >>> >>>>>> >> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with >>>>>> >> >>>> Freeman >>>>>> >> >>>> about this topic several months ago and got to know >>>>>> >> >>>> there won't be Jakarta namespace support work in the future. I >>>>>> >> >>>> don't >>>>>> >> >>>> know if this has changed. >>>>>> >> >>>> Freeman, do you have some update on this ? >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com> >>>>>> >> wrote: >>>>>> >> >>>> >>>>>> >> >>>>> Hey Jim, >>>>>> >> >>>>> >>>>>> >> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are >>>>>> >> >>>>> real >>>>>> >> >>>>> blockers. For Swagger 1.x, we could >>>>>> >> >>>>> go ahead and drop the support altogether, this is quite isolated >>>>>> >> >>>>> feature. OSGi and Karaf are not, those >>>>>> >> >>>>> penetrated very deep into core. What worries me, if we drop >>>>>> >> everything >>>>>> >> >>>>> OSGi/Karaf related from 4.0.0, we >>>>>> >> >>>>> may need to bring it back some time in the future (with OSGi R9 >>>>>> >> >>>>> [4] >>>>>> >> fe) >>>>>> >> >>>>> and that is going to be quite >>>>>> >> >>>>> difficult. From other side, this is probably the only option to >>>>>> >> >>>>> have >>>>>> >> >>>>> 4.0.0 milestone out (we excluded some >>>>>> >> >>>>> modules from the build right now but that is more like a >>>>>> >> >>>>> temporary >>>>>> >> hack >>>>>> >> >>>>> which we should not release upon, >>>>>> >> >>>>> even alphas). What do you think guys? >>>>>> >> >>>>> >>>>>> >> >>>>> Best Regards, >>>>>> >> >>>>> Andriy Redko >>>>>> >> >>>>> >>>>>> >> >>>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >>>>>> >> >>>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >>>>>> >> >>>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >>>>>> >> >>>>> [4] https://github.com/osgi/osgi/milestone/5 >>>>>> >> >>>>> >>>>>> >> >>>>> JM> After we merged the jakarta branch to default branch main >>>>>> >> >>>>> branch, >>>>>> >> >>>>> do we >>>>>> >> >>>>> JM> need to create some >>>>>> >> >>>>> JM> plan to do a future 4.x release? >>>>>> >> >>>>> >>>>>> >> >>>>> JM> There are a couple of to-do things under >>>>>> >> >>>>> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >>>>>> >> >>>>> JM> and for some of them we can't do more things because of the >>>>>> >> jakarta >>>>>> >> >>>>> JM> dependency missing. It seems that some of the dependencies >>>>>> >> >>>>> won't >>>>>> >> >>>>> JM> have the jakarta namespace artifact released in the near >>>>>> >> >>>>> future. >>>>>> >> >>>>> Should we >>>>>> >> >>>>> JM> have some milestone/alpha release >>>>>> >> >>>>> JM> before all these dependencies are available ? And if we >>>>>> >> >>>>> want to >>>>>> >> do >>>>>> >> >>>>> a >>>>>> >> >>>>> JM> milestone release, what do you think we should have in >>>>>> >> >>>>> JM> this 4.0.0-M1 release ? >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> JM> Thanks, >>>>>> >> >>>>> JM> Jim >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma >>>>>> >> >>>>> <mail2ji...@gmail.com> >>>>>> >> >>>>> wrote: >>>>>> >> >>>>> >>>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward ! >>>>>> >> >>>>> >> >>>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko >>>>>> >> >>>>> >> <drr...@gmail.com> >>>>>> >> >>>>> wrote: >>>>>> >> >>>>> >> >>>>>> >> >>>>> >>> Hey guys, >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> The Jakarta branch [1] just went into master, HUGE THANKS >>>>>> >> everyone >>>>>> >> >>>>> for >>>>>> >> >>>>> >>> tremendous effort! Please >>>>>> >> >>>>> >>> note, it is still work in progress, the things to be done >>>>>> >> >>>>> >>> are >>>>>> >> >>>>> tracked >>>>>> >> >>>>> >>> under [2], feel free to >>>>>> >> >>>>> >>> add more items or pick the existing ones. The master builds >>>>>> >> >>>>> >>> still >>>>>> >> >>>>> have >>>>>> >> >>>>> >>> some tests failing, but those >>>>>> >> >>>>> >>> should be fixed shortly. With that, 3.6.x-fixes becomes the >>>>>> >> >>>>> "mirror" of >>>>>> >> >>>>> >>> the master but for javax.* >>>>>> >> >>>>> >>> packages. Cherrypicking / backporting changes from master >>>>>> >> >>>>> >>> might >>>>>> >> be >>>>>> >> >>>>> a bit >>>>>> >> >>>>> >>> more complicated (jakarta.* -> javax.*) >>>>>> >> >>>>> >>> but manageable. >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> One more thing, the pull requests against master and 3.6.x / >>>>>> >> 3.5.x >>>>>> >> >>>>> are >>>>>> >> >>>>> >>> build using JDK-17 now (was JDK-11 >>>>>> >> >>>>> >>> before), this is due to the fact that master needs JDK-17, >>>>>> >> >>>>> >>> as >>>>>> >> it's >>>>>> >> >>>>> Spring >>>>>> >> >>>>> >>> 6 / Spring Boot 3 JDK baseline. >>>>>> >> >>>>> >>> I have difficulties configuring Jenkins Maven builds + >>>>>> >> >>>>> >>> Github >>>>>> >> Pull >>>>>> >> >>>>> >>> Request builder per branch. It may be >>>>>> >> >>>>> >>> possible with pipeline, I will experiment with that. Please >>>>>> >> >>>>> >>> share >>>>>> >> >>>>> any >>>>>> >> >>>>> >>> concerns, comments or feedback, it >>>>>> >> >>>>> >>> is highly appreciated. >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> Thank you! >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> [1] https://github.com/apache/cxf/pull/912 >>>>>> >> >>>>> >>> [2] https://issues.apache.org/jira/browse/CXF-8371 >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> Best Regards, >>>>>> >> >>>>> >>> Andriy Redko >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> COh> +1 from me. >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> COh> Colm. >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>> COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma < >>>>>> >> mail2ji...@gmail.com> >>>>>> >> >>>>> wrote: >>>>>> >> >>>>> >>> >> >>>>>> >> >>>>> >>> >> Hi Andriy, >>>>>> >> >>>>> >>> >> A good plan. I agree with all these changes and support >>>>>> >> versions. >>>>>> >> >>>>> >>> >> >>>>>> >> >>>>> >>> >> Thanks, >>>>>> >> >>>>> >>> >> Jim >>>>>> >> >>>>> >>> >> >>>>>> >> >>>>> >>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko < >>>>>> >> drr...@gmail.com> >>>>>> >> >>>>> >>> wrote: >>>>>> >> >>>>> >>> >> >>>>>> >> >>>>> >>> >> > Hey folks, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > While the work on 4.x / Jakarta is slowly but steadily >>>>>> >> moving >>>>>> >> >>>>> >>> forward, it >>>>>> >> >>>>> >>> >> > is >>>>>> >> >>>>> >>> >> > time to think about next 3.x release line. As we >>>>>> >> >>>>> >>> >> > discussed >>>>>> >> in >>>>>> >> >>>>> this >>>>>> >> >>>>> >>> thread, >>>>>> >> >>>>> >>> >> > it >>>>>> >> >>>>> >>> >> > seems we agreed on 3.6.x to be next javax.* based >>>>>> >> >>>>> >>> >> > release, >>>>>> >> with >>>>>> >> >>>>> >>> JDK-11 as >>>>>> >> >>>>> >>> >> > the >>>>>> >> >>>>> >>> >> > baseline. We have new Spring Boot 2.7.0 just released >>>>>> >> >>>>> >>> >> > [1], >>>>>> >> >>>>> along >>>>>> >> >>>>> >>> with tons >>>>>> >> >>>>> >>> >> > of other >>>>>> >> >>>>> >>> >> > related projects. I would like to propose to: >>>>>> >> >>>>> >>> >> > - branch off 3.6.x-fixes (from master) and work on >>>>>> >> >>>>> >>> >> > upgrades >>>>>> >> >>>>> (+ some >>>>>> >> >>>>> >>> new >>>>>> >> >>>>> >>> >> > features) >>>>>> >> >>>>> >>> >> > - as per @Jim suggestion, merge (very soon) Jakarta >>>>>> >> >>>>> >>> >> > branch >>>>>> >> >>>>> [2] into >>>>>> >> >>>>> >>> master >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > From the support perspective, it means we would need to >>>>>> >> >>>>> maintain >>>>>> >> >>>>> >>> 3.4.x for >>>>>> >> >>>>> >>> >> > some >>>>>> >> >>>>> >>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at >>>>>> >> >>>>> >>> >> > some >>>>>> >> >>>>> point). >>>>>> >> >>>>> >>> What do >>>>>> >> >>>>> >>> >> > you >>>>>> >> >>>>> >>> >> > think guys? Thank you! >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > [1] >>>>>> >> >>>>> >>> >>>>>> >> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now >>>>>> >> >>>>> >>> >> > [2] https://github.com/apache/cxf/pull/912 >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > Best Regards, >>>>>> >> >>>>> >>> >> > Andriy Redko >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > JM> Hi Andriy, >>>>>> >> >>>>> >>> >> > JM> I took some time to look at the CXF java11 support >>>>>> >> >>>>> >>> >> > and >>>>>> >> >>>>> spring >>>>>> >> >>>>> >>> >> > decoupling >>>>>> >> >>>>> >>> >> > JM> last week. >>>>>> >> >>>>> >>> >> > JM> Here are some thoughts and initial work: >>>>>> >> >>>>> >>> >> > JM> 1) Use cross compile to support java11 . We can >>>>>> >> >>>>> >>> >> > simply >>>>>> >> >>>>> change >>>>>> >> >>>>> >>> >> > JM> <cxf.jdk.version> in pom.xml to 11. >>>>>> >> >>>>> >>> >> > JM> This will allow the maven compiler plugin to >>>>>> >> >>>>> >>> >> > build >>>>>> >> cxf >>>>>> >> >>>>> with >>>>>> >> >>>>> >>> java11. >>>>>> >> >>>>> >>> >> > JM> 2) We can look at creating some separate modules >>>>>> >> >>>>> >>> >> > for >>>>>> >> Spring >>>>>> >> >>>>> >>> relevant >>>>>> >> >>>>> >>> >> > JM> code/configuration in the future. Ideally a small >>>>>> >> >>>>> >>> >> > JM> number of modules would be better and it will >>>>>> >> >>>>> >>> >> > make it >>>>>> >> >>>>> easy for >>>>>> >> >>>>> >>> users >>>>>> >> >>>>> >>> >> > to >>>>>> >> >>>>> >>> >> > JM> import spring relevant dependencies. >>>>>> >> >>>>> >>> >> > JM> Here is my initial work : >>>>>> >> >>>>> >>> >> > https://github.com/jimma/cxf/commits/spring >>>>>> >> >>>>> >>> >> > JM> <https://github.com/jimma/cxf/commits/spring>. This >>>>>> >> only >>>>>> >> >>>>> touches >>>>>> >> >>>>> >>> >> > several >>>>>> >> >>>>> >>> >> > JM> cxf modules, I am not >>>>>> >> >>>>> >>> >> > JM> sure if this approach will get other blockers and >>>>>> >> issues. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > JM> Thanks, >>>>>> >> >>>>> >>> >> > JM> Jim >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko < >>>>>> >> >>>>> drr...@gmail.com> >>>>>> >> >>>>> >>> >> > wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> Hey Jim, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> AFAIR this particular topic has popped up several >>>>>> >> >>>>> >>> >> > >> times, >>>>>> >> a >>>>>> >> >>>>> few >>>>>> >> >>>>> >>> issues >>>>>> >> >>>>> >>> >> > >> exist [1] and >>>>>> >> >>>>> >>> >> > >> @Christian even did the POC several years ago [2] in >>>>>> >> >>>>> attempt to >>>>>> >> >>>>> >>> remove >>>>>> >> >>>>> >>> >> > >> some of the >>>>>> >> >>>>> >>> >> > >> hard Spring dependencies (I don't know the outcomes >>>>>> >> >>>>> >>> >> > >> to be >>>>>> >> >>>>> fair >>>>>> >> >>>>> >>> but I >>>>>> >> >>>>> >>> >> > >> suspect it turned >>>>>> >> >>>>> >>> >> > >> out to be much more difficult than anticipated). >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> The suggestion I have in mind is to keep JDK-17 >>>>>> >> >>>>> >>> >> > >> baseline >>>>>> >> >>>>> **for >>>>>> >> >>>>> >>> now** and >>>>>> >> >>>>> >>> >> > >> continue working >>>>>> >> >>>>> >>> >> > >> on addressing the blockers (there too many at this >>>>>> >> point). >>>>>> >> >>>>> Once >>>>>> >> >>>>> >>> we get >>>>>> >> >>>>> >>> >> > to >>>>>> >> >>>>> >>> >> > >> the state when >>>>>> >> >>>>> >>> >> > >> the Jakarta branch is at least buildable / >>>>>> >> >>>>> >>> >> > >> deployable, we >>>>>> >> >>>>> could >>>>>> >> >>>>> >>> reassess >>>>>> >> >>>>> >>> >> > >> the Spring >>>>>> >> >>>>> >>> >> > >> coupling. I am just afraid doing everything at once >>>>>> >> >>>>> >>> >> > >> would >>>>>> >> >>>>> >>> introduce >>>>>> >> >>>>> >>> >> > >> instability in >>>>>> >> >>>>> >>> >> > >> codebase and slow down everyone on either of these >>>>>> >> efforts. >>>>>> >> >>>>> Not >>>>>> >> >>>>> >>> sure if >>>>>> >> >>>>> >>> >> > >> you agree but >>>>>> >> >>>>> >>> >> > >> in any case I am definitely +1 for reducing the >>>>>> >> >>>>> >>> >> > >> scope of >>>>>> >> >>>>> >>> dependencies on >>>>>> >> >>>>> >>> >> > >> Spring, even >>>>>> >> >>>>> >>> >> > >> in 3.4.x / 3.5.x release lines. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> Thank you. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> [1] https://issues.apache.org/jira/browse/CXF-5477 >>>>>> >> >>>>> >>> >> > >> [2] >>>>>> >> https://github.com/apache/cxf/tree/poc-remove-spring-bp >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> Best Regards, >>>>>> >> >>>>> >>> >> > >> Andriy Redko >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> JM> I accidentally clicked the send button, please >>>>>> >> ignore >>>>>> >> >>>>> my >>>>>> >> >>>>> >>> previous >>>>>> >> >>>>> >>> >> > >> email >>>>>> >> >>>>> >>> >> > >> JM> and look at this reply. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> JM> On Sat, Jan 29, 2022 at 7:58 PM Jim Ma < >>>>>> >> >>>>> mail2ji...@gmail.com> >>>>>> >> >>>>> >>> >> > wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko < >>>>>> >> >>>>> >>> drr...@gmail.com> >>>>>> >> >>>>> >>> >> > wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> Hey guys, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> A bunch of good things have happened at the end >>>>>> >> >>>>> >>> >> > >> >>> of >>>>>> >> this >>>>>> >> >>>>> year. >>>>>> >> >>>>> >>> The >>>>>> >> >>>>> >>> >> > 3.5.0 >>>>>> >> >>>>> >>> >> > >> >>> out and we are in a good >>>>>> >> >>>>> >>> >> > >> >>> shape to kick off Jakarta support: the Spring 6 >>>>>> >> >>>>> milestones and >>>>>> >> >>>>> >>> >> > Spring >>>>>> >> >>>>> >>> >> > >> >>> Boot 3 snapshots are already >>>>>> >> >>>>> >>> >> > >> >>> available. There are tons of things to fix and >>>>>> >> address, >>>>>> >> >>>>> I have >>>>>> >> >>>>> >>> >> > created >>>>>> >> >>>>> >>> >> > >> >>> this draft pull request [1] >>>>>> >> >>>>> >>> >> > >> >>> with a first batch of changes and TODOs. >>>>>> >> >>>>> >>> >> > >> >>> Everyone >>>>>> >> >>>>> should be >>>>>> >> >>>>> >>> able to >>>>>> >> >>>>> >>> >> > >> push >>>>>> >> >>>>> >>> >> > >> >>> changes in there, if not >>>>>> >> >>>>> >>> >> > >> >>> - please let me know, I could give perms / move >>>>>> >> >>>>> >>> >> > >> >>> the >>>>>> >> >>>>> branch to >>>>>> >> >>>>> >>> CXF >>>>>> >> >>>>> >>> >> > >> Github >>>>>> >> >>>>> >>> >> > >> >>> repo. Hope in the next >>>>>> >> >>>>> >>> >> > >> >>> couple of months we get closer to fully embrace >>>>>> >> Jakarta. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> On the not so good news side, Spring 6 has kept >>>>>> >> JDK-17 >>>>>> >> >>>>> >>> baseline. It >>>>>> >> >>>>> >>> >> > >> does >>>>>> >> >>>>> >>> >> > >> >>> not play well with our >>>>>> >> >>>>> >>> >> > >> >>> original plan to stick to JDK-11 baseline for >>>>>> >> >>>>> >>> >> > >> >>> 4.x >>>>>> >> but I >>>>>> >> >>>>> am >>>>>> >> >>>>> >>> not sure >>>>>> >> >>>>> >>> >> > we >>>>>> >> >>>>> >>> >> > >> >>> have any choice here besides >>>>>> >> >>>>> >>> >> > >> >>> bumping the baseline as well. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> JM> From the JakartaEE9 release[1]and JakartaEE10 >>>>>> >> >>>>> plan[2], it >>>>>> >> >>>>> >>> still >>>>>> >> >>>>> >>> >> > >> needs to >>>>>> >> >>>>> >>> >> > >> JM> support JDK11. Jakarta Restful WebService >>>>>> >> >>>>> >>> >> > >> 3.0/3.1 >>>>>> >> and >>>>>> >> >>>>> >>> Jakarta XML >>>>>> >> >>>>> >>> >> > Web >>>>>> >> >>>>> >>> >> > >> JM> Services 3.0/3.1 >>>>>> >> >>>>> >>> >> > >> JM> apis are the specifications we need to >>>>>> >> >>>>> >>> >> > >> implement in >>>>>> >> >>>>> CXF, so >>>>>> >> >>>>> >>> we >>>>>> >> >>>>> >>> >> > need >>>>>> >> >>>>> >>> >> > >> to >>>>>> >> >>>>> >>> >> > >> JM> build, run and test implementation with JDK11. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> JM> Just thinking this loud, is it possible that >>>>>> >> >>>>> >>> >> > >> we >>>>>> >> make >>>>>> >> >>>>> Spring >>>>>> >> >>>>> >>> >> > plugable >>>>>> >> >>>>> >>> >> > >> or >>>>>> >> >>>>> >>> >> > >> JM> really optional ? 4.x is the major release and >>>>>> >> >>>>> >>> >> > >> it's >>>>>> >> the >>>>>> >> >>>>> >>> chance >>>>>> >> >>>>> >>> >> > >> JM> to refactor CXF code(like we move spring >>>>>> >> >>>>> >>> >> > >> related >>>>>> >> >>>>> >>> source/test to >>>>>> >> >>>>> >>> >> > >> separate >>>>>> >> >>>>> >>> >> > >> JM> module) to build/run/test without Spring with a >>>>>> >> >>>>> >>> >> > >> maven >>>>>> >> >>>>> profile. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> JM> [1] >>>>>> >> >>>>> >>> >> > >> JM> >>>>>> >> >>>>> >>> >> > >> >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>>>>> >> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan >>>>>> >> >>>>> >>> >> > >> JM> [2] >>>>>> >> >>>>> >>> >> > >> JM> >>>>>> >> >>>>> >>> >> > >> >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>>>>> >> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> Happy Holidays guys! >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> [1] https://github.com/apache/cxf/pull/888 >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy Redko >>>>>> >> >>>>> >>> >> > >> >>> < >>>>>> >> >>>>> >>> drr...@gmail.com> >>>>>> >> >>>>> >>> >> > >> wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> Hey Jim, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> No, we don't have a branch just yet, >>>>>> >> >>>>> >>> >> > >> >>> >> primarily >>>>>> >> >>>>> because we >>>>>> >> >>>>> >>> depend >>>>>> >> >>>>> >>> >> > on >>>>>> >> >>>>> >>> >> > >> the >>>>>> >> >>>>> >>> >> > >> >>> >> few >>>>>> >> >>>>> >>> >> > >> >>> >> snapshots in 3.5.0/master. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> @Colm do you have an idea regarding xmlschema >>>>>> >> 2.3.0 >>>>>> >> >>>>> release >>>>>> >> >>>>> >>> >> > >> timelines? >>>>>> >> >>>>> >>> >> > >> >>> >> @Dan do you have an idea regarding neethi >>>>>> >> >>>>> >>> >> > >> >>> >> 3.2.0 >>>>>> >> >>>>> release >>>>>> >> >>>>> >>> >> > timelines? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> At worst, you could create a new branch for >>>>>> >> >>>>> >>> >> > >> >>> >> this >>>>>> >> >>>>> feature, >>>>>> >> >>>>> >>> or >>>>>> >> >>>>> >>> >> > submit >>>>>> >> >>>>> >>> >> > >> a >>>>>> >> >>>>> >>> >> > >> >>> >> pull request against master which we should >>>>>> >> >>>>> >>> >> > >> >>> >> be >>>>>> >> able >>>>>> >> >>>>> to >>>>>> >> >>>>> >>> re-target >>>>>> >> >>>>> >>> >> > >> later >>>>>> >> >>>>> >>> >> > >> >>> >> against the right branch (should be easy). >>>>>> >> >>>>> >>> >> > >> >>> >> What do >>>>>> >> >>>>> you >>>>>> >> >>>>> >>> think? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> JM> This is a good idea. I'll send a PR against >>>>>> >> >>>>> >>> >> > >> >>> the >>>>>> >> >>>>> master, >>>>>> >> >>>>> >>> and >>>>>> >> >>>>> >>> >> > later >>>>>> >> >>>>> >>> >> > >> we >>>>>> >> >>>>> >>> >> > >> >>> can >>>>>> >> >>>>> >>> >> > >> >>> JM> decide the place to merge. >>>>>> >> >>>>> >>> >> > >> >>> JM> Thanks, Andriy. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> Best Regards, >>>>>> >> >>>>> >>> >> > >> >>> >> Andriy Redko >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> JM> Thanks for more updates , Andriy. >>>>>> >> >>>>> >>> >> > >> >>> >> JM> Is there a place/workspace branch, I can >>>>>> >> send a >>>>>> >> >>>>> PR >>>>>> >> >>>>> >>> for this >>>>>> >> >>>>> >>> >> > >> >>> change? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> JM> On Fri, Sep 3, 2021 at 9:20 PM Andriy >>>>>> >> >>>>> >>> >> > >> >>> >> Redko < >>>>>> >> >>>>> >>> >> > drr...@gmail.com> >>>>>> >> >>>>> >>> >> > >> >>> wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> Hey Jim, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> Thanks a lot for taking the lead on this >>>>>> >> >>>>> >>> >> > >> >>> >> >> one. >>>>>> >> >>>>> Just want >>>>>> >> >>>>> >>> to >>>>>> >> >>>>> >>> >> > chime >>>>>> >> >>>>> >>> >> > >> in >>>>>> >> >>>>> >>> >> > >> >>> on a >>>>>> >> >>>>> >>> >> > >> >>> >> >> few points. Indeed, as >>>>>> >> >>>>> >>> >> > >> >>> >> >> per previous discussion in this thread, it >>>>>> >> seems >>>>>> >> >>>>> like >>>>>> >> >>>>> >>> it make >>>>>> >> >>>>> >>> >> > >> sense >>>>>> >> >>>>> >>> >> > >> >>> to >>>>>> >> >>>>> >>> >> > >> >>> >> >> provide only the subset >>>>>> >> >>>>> >>> >> > >> >>> >> >> of shaded modules with Jakarta namespace. >>>>>> >> >>>>> >>> >> > >> >>> >> >> Also, >>>>>> >> >>>>> it was >>>>>> >> >>>>> >>> >> > confirmed >>>>>> >> >>>>> >>> >> > >> >>> >> yesterday >>>>>> >> >>>>> >>> >> > >> >>> >> >> that Spring Framework >>>>>> >> >>>>> >>> >> > >> >>> >> >> 6 milestones will be available in >>>>>> >> >>>>> >>> >> > >> >>> >> >> November this >>>>>> >> >>>>> year >>>>>> >> >>>>> >>> but the >>>>>> >> >>>>> >>> >> > >> first >>>>>> >> >>>>> >>> >> > >> >>> >> >> snapshots will be out in late >>>>>> >> >>>>> >>> >> > >> >>> >> >> September / early October, looks pretty >>>>>> >> >>>>> promising. One >>>>>> >> >>>>> >>> >> > >> >>> **unexpected** >>>>>> >> >>>>> >>> >> > >> >>> >> part >>>>>> >> >>>>> >>> >> > >> >>> >> >> of the announcement >>>>>> >> >>>>> >>> >> > >> >>> >> >> is JDK17 baseline for Spring Framework & >>>>>> >> >>>>> >>> >> > >> >>> >> >> Co, >>>>>> >> that >>>>>> >> >>>>> could >>>>>> >> >>>>> >>> be a >>>>>> >> >>>>> >>> >> > >> bummer >>>>>> >> >>>>> >>> >> > >> >>> but >>>>>> >> >>>>> >>> >> > >> >>> >> I >>>>>> >> >>>>> >>> >> > >> >>> >> >> have the feeling that >>>>>> >> >>>>> >>> >> > >> >>> >> >> it will be lowered to JDK11. Thank you. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> Best Regards, >>>>>> >> >>>>> >>> >> > >> >>> >> >> Andriy Redko >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> Good point, Romain. We need to look >>>>>> >> >>>>> >>> >> > >> >>> >> >> at what >>>>>> >> >>>>> to do >>>>>> >> >>>>> >>> to make >>>>>> >> >>>>> >>> >> > >> sure >>>>>> >> >>>>> >>> >> > >> >>> all >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> artifacts are included and >>>>>> >> >>>>> >>> >> > >> >>> >> >> transformed if >>>>>> >> this >>>>>> >> >>>>> >>> becomes a >>>>>> >> >>>>> >>> >> > cxf >>>>>> >> >>>>> >>> >> > >> >>> module. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> BTW, Spring 6 GA supports jakarta >>>>>> >> >>>>> >>> >> > >> >>> >> >> ee9 will >>>>>> >> >>>>> come in >>>>>> >> >>>>> >>> Q4 >>>>>> >> >>>>> >>> >> > 2022 : >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> >> >>>>> >>> >> > >> >>> >> >>>>>> >> >>>>> >>> >> > >> >>> >>>>>> >> >>>>> >>> >> > >> >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>>>>> >> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> On Fri, Sep 3, 2021 at 6:20 PM Romain >>>>>> >> >>>>> Manni-Bucau < >>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com> >>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma < >>>>>> >> >>>>> >>> mail2ji...@gmail.com> >>>>>> >> >>>>> >>> >> > a >>>>>> >> >>>>> >>> >> > >> >>> écrit >>>>>> >> >>>>> >>> >> > >> >>> >> : >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain >>>>>> >> >>>>> Manni-Bucau < >>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> < >>>>>> >> >>>>> >>> >> > mail2ji...@gmail.com> >>>>>> >> >>>>> >>> >> > >> a >>>>>> >> >>>>> >>> >> > >> >>> >> écrit : >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Romain >>>>>> >> >>>>> >>> Manni-Bucau < >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibu...@gmail.com> wrote: >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Andriy >>>>>> >> Redko >>>>>> >> >>>>> < >>>>>> >> >>>>> >>> >> > >> drr...@gmail.com> >>>>>> >> >>>>> >>> >> > >> >>> a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> écrit : >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Hi Romain, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Sorry for the delayed response. I >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have >>>>>> >> >>>>> been >>>>>> >> >>>>> >>> thinking >>>>>> >> >>>>> >>> >> > >> about >>>>>> >> >>>>> >>> >> > >> >>> your >>>>>> >> >>>>> >>> >> > >> >>> >> >> (and >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Jim) suggestions >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> and came to surprising >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> conclusion: do >>>>>> >> we >>>>>> >> >>>>> >>> actually >>>>>> >> >>>>> >>> >> > need to >>>>>> >> >>>>> >>> >> > >> >>> >> >> officially >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> release anything >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> to shade/overwrite javax <-> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta? >>>>>> >> >>>>> >>> Generally, we >>>>>> >> >>>>> >>> >> > could >>>>>> >> >>>>> >>> >> > >> >>> shade >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Spring or/and any other >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> dependency but we would certainly >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> not >>>>>> >> >>>>> bundle it >>>>>> >> >>>>> >>> as >>>>>> >> >>>>> >>> >> > part >>>>>> >> >>>>> >>> >> > >> of >>>>>> >> >>>>> >>> >> > >> >>> CXF >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> distribution (I hope you >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> would agree), so not really useful >>>>>> >> unless >>>>>> >> >>>>> we >>>>>> >> >>>>> >>> publish >>>>>> >> >>>>> >>> >> > >> them. >>>>>> >> >>>>> >>> >> > >> >>> As >>>>>> >> >>>>> >>> >> > >> >>> >> such, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> probably the best >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> interim solution is to document >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> what it >>>>>> >> >>>>> takes >>>>>> >> >>>>> >>> to shade >>>>>> >> >>>>> >>> >> > >> CXF >>>>>> >> >>>>> >>> >> > >> >>> >> (javax >>>>>> >> >>>>> >>> >> > >> >>> >> >> <-> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta) and let >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> the end users (application/service >>>>>> >> >>>>> developers) >>>>>> >> >>>>> >>> use >>>>>> >> >>>>> >>> >> > that >>>>>> >> >>>>> >>> >> > >> when >>>>>> >> >>>>> >>> >> > >> >>> >> >> needed? >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> In this case >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> basically CXF, Spring, Geronimo, >>>>>> >> Swagger, >>>>>> >> >>>>> ... >>>>>> >> >>>>> >>> would >>>>>> >> >>>>> >>> >> > >> follow >>>>>> >> >>>>> >>> >> > >> >>> the >>>>>> >> >>>>> >>> >> > >> >>> >> same >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> shading rules. At >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> least, we could start with that >>>>>> >> >>>>> (documenting the >>>>>> >> >>>>> >>> >> > shading >>>>>> >> >>>>> >>> >> > >> >>> >> process) >>>>>> >> >>>>> >>> >> > >> >>> >> >> and >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> likely get some >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> early feedback while working on >>>>>> >> >>>>> full-fledged >>>>>> >> >>>>> >>> support? >>>>>> >> >>>>> >>> >> > >> WDYT? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> This is what is done and makes it >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> hard >>>>>> >> for >>>>>> >> >>>>> >>> nothing to >>>>>> >> >>>>> >>> >> > >> >>> >> maintain/fix - >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> dont even look at tomee solution >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> for >>>>>> >> >>>>> shading >>>>>> >> >>>>> >>> please ;) >>>>>> >> >>>>> >>> >> > - >>>>>> >> >>>>> >>> >> > >> >>> IMHO. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Being said it costs nothing to cxf >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> to >>>>>> >> >>>>> produce >>>>>> >> >>>>> >>> jakarta >>>>>> >> >>>>> >>> >> > >> jars, >>>>>> >> >>>>> >>> >> > >> >>> that >>>>>> >> >>>>> >>> >> > >> >>> >> it >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> makes it ee 9 compliant and more >>>>>> >> >>>>> consistent for >>>>>> >> >>>>> >>> all but >>>>>> >> >>>>> >>> >> > >> >>> spring >>>>>> >> >>>>> >>> >> > >> >>> >> >> usage (ee >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> integrators, plain tomcat 10 users >>>>>> >> >>>>> etc...), I >>>>>> >> >>>>> >>> think it >>>>>> >> >>>>> >>> >> > is >>>>>> >> >>>>> >>> >> > >> >>> worth >>>>>> >> >>>>> >>> >> > >> >>> >> >> doing it, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> at minimum. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> At least a jakarta jaxrs (over >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> jakarta >>>>>> >> >>>>> servlet) >>>>>> >> >>>>> >>> bundle >>>>>> >> >>>>> >>> >> > >> would >>>>>> >> >>>>> >>> >> > >> >>> be a >>>>>> >> >>>>> >>> >> > >> >>> >> >> good >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> progress, not sure jaxws and other >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> parts >>>>>> >> >>>>> would be >>>>>> >> >>>>> >>> >> > helpful >>>>>> >> >>>>> >>> >> > >> >>> since >>>>>> >> >>>>> >>> >> > >> >>> >> >> they tend >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> to be in maintainance mode from >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> what I >>>>>> >> saw. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> So IMHO the best is a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> shade/relocation >>>>>> >> in >>>>>> >> >>>>> the >>>>>> >> >>>>> >>> parent to >>>>>> >> >>>>> >>> >> > >> >>> deliver a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> jakarta artifact for all module + >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> a few >>>>>> >> >>>>> jakarta >>>>>> >> >>>>> >>> bom. >>>>>> >> >>>>> >>> >> > But >>>>>> >> >>>>> >>> >> > >> if >>>>>> >> >>>>> >>> >> > >> >>> too >>>>>> >> >>>>> >>> >> > >> >>> >> >> much - >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> which I can see/hear - a jakarta >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> jaxrs >>>>>> >> >>>>> bundle >>>>>> >> >>>>> >>> would >>>>>> >> >>>>> >>> >> > work >>>>>> >> >>>>> >>> >> > >> too >>>>>> >> >>>>> >>> >> > >> >>> >> short >>>>>> >> >>>>> >>> >> > >> >>> >> >> term. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> I agree to start with something to >>>>>> >> preview >>>>>> >> >>>>> and >>>>>> >> >>>>> >>> collect >>>>>> >> >>>>> >>> >> > more >>>>>> >> >>>>> >>> >> > >> >>> ideas >>>>>> >> >>>>> >>> >> > >> >>> >> to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> support ee9. It's good to have a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> branch >>>>>> >> to >>>>>> >> >>>>> really >>>>>> >> >>>>> >>> start >>>>>> >> >>>>> >>> >> > >> >>> something >>>>>> >> >>>>> >>> >> > >> >>> >> >> for this >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> topic. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> @Romain, do you have a prototype >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> with >>>>>> >> >>>>> shading or >>>>>> >> >>>>> >>> other >>>>>> >> >>>>> >>> >> > >> tools >>>>>> >> >>>>> >>> >> > >> >>> for a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> jakarta jaxrs bundle or just some >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> basic >>>>>> >> >>>>> idea that >>>>>> >> >>>>> >>> we can >>>>>> >> >>>>> >>> >> > >> have >>>>>> >> >>>>> >>> >> > >> >>> a >>>>>> >> >>>>> >>> >> > >> >>> >> look >>>>>> >> >>>>> >>> >> > >> >>> >> >> at ? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Not ready for cxf but looking at >>>>>> >> >>>>> meecrowave-core >>>>>> >> >>>>> >>> pom you >>>>>> >> >>>>> >>> >> > >> would >>>>>> >> >>>>> >>> >> > >> >>> have >>>>>> >> >>>>> >>> >> > >> >>> >> >> some >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> idea. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> I just suspect pom deps need some >>>>>> >> refinement >>>>>> >> >>>>> like >>>>>> >> >>>>> >>> >> > >> with/without >>>>>> >> >>>>> >>> >> > >> >>> the >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> client (it is useless with java 11 >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> now and >>>>>> >> >>>>> less >>>>>> >> >>>>> >>> and less >>>>>> >> >>>>> >>> >> > >> >>> desired >>>>>> >> >>>>> >>> >> > >> >>> >> >> AFAIK). >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> @Romain Manni-Bucau < >>>>>> >> rmannibu...@gmail.com> >>>>>> >> >>>>> >>> Thanks for >>>>>> >> >>>>> >>> >> > the >>>>>> >> >>>>> >>> >> > >> >>> >> update. I >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> looked at the meecrowave-core pom and >>>>>> >> >>>>> understood >>>>>> >> >>>>> >>> how it >>>>>> >> >>>>> >>> >> > >> >>> transforms >>>>>> >> >>>>> >>> >> > >> >>> >> >> package >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> names with the shade plugin. Both >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> shade >>>>>> >> >>>>> plugin or >>>>>> >> >>>>> >>> eclipse >>>>>> >> >>>>> >>> >> > >> >>> >> transformer >>>>>> >> >>>>> >>> >> > >> >>> >> >> tool >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> works for this purpose . >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> I created one prototype project which >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> pulls >>>>>> >> >>>>> in cxf >>>>>> >> >>>>> >>> >> > >> dependencies, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> transforms to jakarta namespace and >>>>>> >> installs >>>>>> >> >>>>> to >>>>>> >> >>>>> >>> local >>>>>> >> >>>>> >>> >> > maven >>>>>> >> >>>>> >>> >> > >> >>> >> >> repository : >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> >>>>>> >> https://github.com/jimma/cxf-ee9-transformer >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> This doesn't need more effort and no >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> need >>>>>> >> the >>>>>> >> >>>>> >>> >> > code/dependency >>>>>> >> >>>>> >>> >> > >> >>> change >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> which breaks/mixes with javax support >>>>>> >> >>>>> codebase. It >>>>>> >> >>>>> >>> can be >>>>>> >> >>>>> >>> >> > >> simply >>>>>> >> >>>>> >>> >> > >> >>> >> added >>>>>> >> >>>>> >>> >> > >> >>> >> >> with >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> another maven module in cxf repo to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> produce >>>>>> >> >>>>> >>> transformed >>>>>> >> >>>>> >>> >> > >> jakata >>>>>> >> >>>>> >>> >> > >> >>> cxf >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> artifacts or binary distribution. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> Your >>>>>> >> >>>>> thoughts ? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> If not all artifacts are proposed with >>>>>> >> jakarta >>>>>> >> >>>>> >>> support it >>>>>> >> >>>>> >>> >> > is >>>>>> >> >>>>> >>> >> > >> an >>>>>> >> >>>>> >>> >> > >> >>> >> option >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> otherwise it would need a build module >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> to >>>>>> >> >>>>> >>> synchronize this >>>>>> >> >>>>> >>> >> > >> >>> >> submodule(s) >>>>>> >> >>>>> >>> >> > >> >>> >> >> to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> ensure none are forgotten - this is >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> where I >>>>>> >> >>>>> prefer >>>>>> >> >>>>> >>> the >>>>>> >> >>>>> >>> >> > >> classifier >>>>>> >> >>>>> >>> >> > >> >>> >> >> approach >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> even if it has this exclusion pitfalls >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> - but >>>>>> >> >>>>> cxf has >>>>>> >> >>>>> >>> it >>>>>> >> >>>>> >>> >> > anyway >>>>>> >> >>>>> >>> >> > >> >>> due to >>>>>> >> >>>>> >>> >> > >> >>> >> >> its >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> transitive dependencies so not worse >>>>>> >> >>>>> >>> >> > >> >>> >> >> >> IMHO >>>>>> >> ;). >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Thanks, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Jim >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Thank you. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Best Regards, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Andriy Redko >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> I'm not sure I see why you >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> need >>>>>> >> >>>>> spring to >>>>>> >> >>>>> >>> start >>>>>> >> >>>>> >>> >> > this >>>>>> >> >>>>> >>> >> > >> >>> work. >>>>>> >> >>>>> >>> >> > >> >>> >> The >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> expected is >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> there already so spring >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> module can >>>>>> >> >>>>> still >>>>>> >> >>>>> >>> rely on >>>>>> >> >>>>> >>> >> > >> >>> javax, be >>>>>> >> >>>>> >>> >> > >> >>> >> >> made >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> friendly using shade plugin >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> or >>>>>> >> alike >>>>>> >> >>>>> and >>>>>> >> >>>>> >>> that's >>>>>> >> >>>>> >>> >> > it >>>>>> >> >>>>> >>> >> > >> >>> until a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> spring native >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> integration is there. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Worse case cxf-spring will >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> not be >>>>>> >> >>>>> usable >>>>>> >> >>>>> >>> with >>>>>> >> >>>>> >>> >> > >> jakarta - >>>>>> >> >>>>> >>> >> > >> >>> >> which >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> still enabled >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> all other usages, best case >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> if >>>>>> >> spring >>>>>> >> >>>>> >>> makes the >>>>>> >> >>>>> >>> >> > >> >>> transition >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> smooth is that >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> it will work smoothly >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> without more >>>>>> >> >>>>> >>> investment >>>>>> >> >>>>> >>> >> > than >>>>>> >> >>>>> >>> >> > >> for >>>>>> >> >>>>> >>> >> > >> >>> the >>>>>> >> >>>>> >>> >> > >> >>> >> >> rest >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> of the >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> build. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> The pro of that options is >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> that it >>>>>> >> >>>>> will >>>>>> >> >>>>> >>> reduce >>>>>> >> >>>>> >>> >> > the >>>>>> >> >>>>> >>> >> > >> >>> number >>>>>> >> >>>>> >>> >> > >> >>> >> of >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> unofficial cxf >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> relocations sooner IMHO. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Romain Manni-Bucau >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> @rmannibucau < >>>>>> >> >>>>> >>> https://twitter.com/rmannibucau> | >>>>>> >> >>>>> >>> >> > >> Blog >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> < >>>>>> >> https://rmannibucau.metawerx.net/> >>>>>> >> >>>>> | Old >>>>>> >> >>>>> >>> Blog >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> <http://rmannibucau.wordpress.com> >>>>>> >> | >>>>>> >> >>>>> >>> Github < >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> https://github.com/rmannibucau> | >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> LinkedIn < >>>>>> >> >>>>> >>> >> > https://www.linkedin.com/in/rmannibucau> >>>>>> >> >>>>> >>> >> > >> | >>>>>> >> >>>>> >>> >> > >> >>> Book >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> < >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> >> >>>>> >>> >> > >> >>> >> >>>>>> >> >>>>> >>> >> > >> >>> >>>>>> >> >>>>> >>> >> > >> >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >>>>>> >> >>>>> >>>>>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Le lun. 16 août 2021 à 23:40, >>>>>> >> Andriy >>>>>> >> >>>>> Redko >>>>>> >> >>>>> >>> < >>>>>> >> >>>>> >>> >> > >> >>> >> drr...@gmail.com> >>>>>> >> >>>>> >>> >> > >> >>> >> >> a >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> écrit : >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Hi Jim, >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> I will try to answer your >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> questions, >>>>>> >> >>>>> other >>>>>> >> >>>>> >>> guys >>>>>> >> >>>>> >>> >> > will >>>>>> >> >>>>> >>> >> > >> >>> >> definitely >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> share more >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> thoughts, please see mine >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> inlined. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> What's the task for JDK-17 >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> LTS >>>>>> >> >>>>> >>> preparation ? >>>>>> >> >>>>> >>> >> > Do we >>>>>> >> >>>>> >>> >> > >> >>> need >>>>>> >> >>>>> >>> >> > >> >>> >> to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> build 3.5.0 with JDK-17 ? >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Build + All tests are green. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Apache Karaf 4.3.3 will support >>>>>> >> JDK17 >>>>>> >> >>>>> so our >>>>>> >> >>>>> >>> OSGi >>>>>> >> >>>>> >>> >> > test >>>>>> >> >>>>> >>> >> > >> >>> suites >>>>>> >> >>>>> >>> >> > >> >>> >> >> will >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> pass. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Besides that, there is still >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> some >>>>>> >> work >>>>>> >> >>>>> to do >>>>>> >> >>>>> >>> [1] >>>>>> >> >>>>> >>> >> > but >>>>>> >> >>>>> >>> >> > >> at >>>>>> >> >>>>> >>> >> > >> >>> >> least we >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> workarounds. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> For Jakarta ee9 support >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> branch >>>>>> >> 4.x >>>>>> >> >>>>> with >>>>>> >> >>>>> >>> source >>>>>> >> >>>>> >>> >> > code >>>>>> >> >>>>> >>> >> > >> >>> >> change to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> jakarta namespace , we have to >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> wait >>>>>> >> for >>>>>> >> >>>>> >>> spring and >>>>>> >> >>>>> >>> >> > >> other >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> third party dependencies >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> jakarta >>>>>> >> ee9 >>>>>> >> >>>>> >>> ready. >>>>>> >> >>>>> >>> >> > Now we >>>>>> >> >>>>> >>> >> > >> >>> don't >>>>>> >> >>>>> >>> >> > >> >>> >> >> know >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> when >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> these dependencies are all >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> ready and >>>>>> >> >>>>> we can >>>>>> >> >>>>> >>> start >>>>>> >> >>>>> >>> >> > this >>>>>> >> >>>>> >>> >> > >> >>> work. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> This is correct, the earliest >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> we >>>>>> >> could >>>>>> >> >>>>> expect >>>>>> >> >>>>> >>> >> > >> something >>>>>> >> >>>>> >>> >> > >> >>> is >>>>>> >> >>>>> >>> >> > >> >>> >> >> Q4/2021 >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> (fe >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Spring). >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> Given there is no features >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> added >>>>>> >> in >>>>>> >> >>>>> >>> Jakarta ee >>>>>> >> >>>>> >>> >> > 9.1 >>>>>> >> >>>>> >>> >> > >> >>> besides >>>>>> >> >>>>> >>> >> > >> >>> >> >> the >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> namespace change, we can >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> provide the >>>>>> >> >>>>> jakarta >>>>>> >> >>>>> >>> >> > calssfier >>>>>> >> >>>>> >>> >> > >> >>> maven >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> artifacts >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> and binary release in 3.6.x >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> or >>>>>> >> 4.x >>>>>> >> >>>>> with >>>>>> >> >>>>> >>> >> > >> >>> transformation or >>>>>> >> >>>>> >>> >> > >> >>> >> >> other >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> better >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> approach will be enough.We >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> provide >>>>>> >> >>>>> jakarta >>>>>> >> >>>>> >>> ee9 >>>>>> >> >>>>> >>> >> > support >>>>>> >> >>>>> >>> >> > >> >>> early, >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> then we can get more >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> feedback on >>>>>> >> >>>>> this >>>>>> >> >>>>> >>> topic. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> It is definitely the option we >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> have >>>>>> >> >>>>> among >>>>>> >> >>>>> >>> others to >>>>>> >> >>>>> >>> >> > >> >>> discuss. >>>>>> >> >>>>> >>> >> > >> >>> >> I >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have no >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> doubts that everyone has rough >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> idea >>>>>> >> of >>>>>> >> >>>>> the >>>>>> >> >>>>> >>> pros and >>>>>> >> >>>>> >>> >> > >> cons >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> each option has, as the team >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> we are >>>>>> >> >>>>> trying >>>>>> >> >>>>> >>> to pick >>>>>> >> >>>>> >>> >> > the >>>>>> >> >>>>> >>> >> > >> >>> best >>>>>> >> >>>>> >>> >> > >> >>> >> path >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> forward. >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Jakarta EE 10 is coming in >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Q1/2022 >>>>>> >> >>>>> [2], we >>>>>> >> >>>>> >>> should >>>>>> >> >>>>> >>> >> > >> keep it >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> in mind as well. >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Thank you! >>>>>> >> >>>>> >>> >> > >>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> [1] >>>>>> >> >>>>> >>>
