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