Hey Jim, Yes, the maven-plugins/wadl2java-plugin is blocked by [1], no Jakarta release. Thanks!
[1] https://github.com/highsource/jaxb2-basics Best Regards, Andriy Redko JM> I already created a branch for the pre-removal and merged this osgi removal JM> change to the main branch . JM> For these test failures and skipped modules, I'll have a look and fill a JM> JIRA for them after I resolve the JM> grizzly jakarta upgrade : https://issues.apache.org/jira/browse/CXF-8716. JM> @Andriy Redko <drr...@gmail.com> Do you remember why we skipped the JM> maven-plugins/wadl2java-plugin and systests/wsdl_maven/codegen ? JM> I remembered we analyzed this before , but I can't find the discussion log. JM> On Wed, Sep 28, 2022 at 4:30 PM Colm O hEigeartaigh <cohei...@apache.org> JM> wrote: >> 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] >> >>>>> >> >>>>> >>> >>
