Hi, No objection from me either. Apart from OSGi, could we make sure that all the gaps are recorded in JIRA?
* Test failures in cxf-rt-mp-client - https://issues.apache.org/jira/browse/CXF-8758 * Test failures in cxf-systests-transports-undertow,cxf-systests-jaxws (websocket related) - https://issues.apache.org/jira/browse/CXF-8717 * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is failing in the jms transport systests - JIRA? * ./systests/container-integration/grizzly skipped - https://issues.apache.org/jira/browse/CXF-8716 * jaxrs systests skipped - JIRA? * systests/wsdl_maven/codegen skipped - JIRA? * maven-plugins/wadl2java-plugin - JIRA? * maven-plugins/java2swagger-plugin - JIRA? Colm. 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] >>>>> >> >>>>> >>>
