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 >> <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 >> <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] >>> >> >>>>> >>> <https://issues.apache.org/jira/browse/CXF-8407> >> >>
