Hey guys, Thanks a lot for bringing the clarity on possible timelines. @Jim, how do you want to proceed with that? Do you think it is good idea to move off Apache Karaf integration into separate repository altogether (we discussed that a few times as well)? Should we preserve the OSGi-related hooks but replace them with "dummy" implementation (like HTTP transport for example)? @Colm, @Freeman what do you think? (assuming the goal is to put this chunk of codebase aside and bring it back when time comes).
Thanks! Best Regards, Andriy Redko > 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>> [2] >>>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Andriy Redko JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 11, 2021 at 8:26 PM >>>> Andriy >>>>>>> Redko < drr...@gmail.com>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hey Jim, Romain, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you guys, I think Romain's >>>>>>> suggestion to >>>>>>>>>> move >>>>>>>>>>>>>>> 3.5.x >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> JDK-11 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseline is good idea, we would >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still be maintaining 3.4.x for a >>>> while, >>>>>>> covering >>>>>>>>>>>> JDK-8 >>>>>>>>>>>>>>>>> based >>>>>>>>>>>>>>>>>>>>>>>>>>>> deployments. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding Jakarta, yes, I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> certainly remember the discussion >>>>>>> regarding the >>>>>>>>>>>> build >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>>>>>>>>>> approach, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> personally with time I came to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusion that this is not the best >>>>>>> option for >>>>>>>>>> at >>>>>>>>>>>>>>> least 2 >>>>>>>>>>>>>>>>>>>>>>>>>> reasons: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - differences between source vs >>>> binary >>>>>>>>>> artifacts >>>>>>>>>>>> are >>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>>>>>>>>>> confusing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (source imports javax, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary has jakarta, or vice >>>> versa), I >>>>>>> think >>>>>>>>>> we >>>>>>>>>>>> all >>>>>>>>>>>>>>> run >>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>>>>>>>>> that from >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> time to time >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Jakarta is the way to go, the >>>>>>> mainstream >>>>>>>>>> should >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just my 5 cents, but we certainly >>>> should >>>>>>>>>> consider >>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>>>>>>>>>>>> as well, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there are good points to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> follow it, summarizing what we have >>>> at the >>>>>>>>>> moment: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Option #1: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - release 3.5.0 in preparation to >>>> JDK-17 >>>>>>> LTS, >>>>>>>>>>>> keeping >>>>>>>>>>>>>>>>> JDK-8 >>>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>> baseline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - move master to 3.6.x (4.x?) with >>>>>>> JDK-11 as >>>>>>>>>> the >>>>>>>>>>>>>>> minimal >>>>>>>>>>>>>>>>>>>>>>>>>> required JDK >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> version (Jetty 10, ...) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - branch off 5.x (4.x?) to continue >>>> the >>>>>>> work on >>>>>>>>>>>>>>>>> supporting >>>>>>>>>>>>>>>>>>>>>>>>>> Jakarta >>>>>>>>>>>>>>>>>>>>>>>>>>>> 9.0+, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with JDK-11 as the minimal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required JDK version (Jetty 11, >>>> ...) JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What's the task for JDK-17 LTS >>>>>>> preparation ? >>>>>>>>>> Do >>>>>>>>>>>> we >>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>>>>>>>>> build JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3.5.0 with JDK-17 ? JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For Jakarta ee9 support branch 4.x >>>> with >>>>>>> source >>>>>>>>>>>> code >>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> support JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jakarta namespace , we have to wait >>>> for >>>>>>> spring >>>>>>>>>> and >>>>>>>>>>>>>>> other JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> third party dependencies jakarta ee9 >>>>>>> ready. >>>>>>>>>> Now >>>>>>>>>>>> we >>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>> know >>>>>>>>>>>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>>>>>>>>>>>> these JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dependencies are all ready and we >>>> can >>>>>>> start >>>>>>>>>> this >>>>>>>>>>>>>>> work. JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Given there is no features added in >>>>>>> Jakarta ee >>>>>>>>>> 9.1 >>>>>>>>>>>>>>>>> besides >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> namespace JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change, we can provide the jakarta >>>>>>> calssfier >>>>>>>>>> maven >>>>>>>>>>>>>>>>> artifacts >>>>>>>>>>>>>>>>>>>>>>>>>> and binary JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in 3.6.x or 4.x with >>>>>>> transformation or >>>>>>>>>>>> other >>>>>>>>>>>>>>>>> better >>>>>>>>>>>>>>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>>>>>>>>>>>>>> will JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be enough.We provide jakarta ee9 >>>> support >>>>>>> early, >>>>>>>>>>>> then >>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>>>>>> get more JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feedback on this topic. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Option #2: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - release 3.5.0 in preparation to >>>> JDK-17 >>>>>>> LTS, >>>>>>>>>> use >>>>>>>>>>>>>>> JDK-11 >>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>> baseline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - handle javax by a build setup >>>> (with api >>>>>>>>>>>> validation >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>>> build >>>>>>>>>>>>>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avoid regressions) and use jakarta >>>>>>> package as >>>>>>>>>> main >>>>>>>>>>>>>>> api in >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> project >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Romain), or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding a new maven module to >>>> transform >>>>>>> cxf >>>>>>>>>>>>>>> artifacts >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>>>>> jakarta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> package name (Jim) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Option #3: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - release 3.5.0 in preparation to >>>> JDK-17 >>>>>>> LTS, >>>>>>>>>> use >>>>>>>>>>>>>>> JDK-11 >>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>> baseline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - move master to 4.x to continue the >>>>>>> work on >>>>>>>>>>>>>>> supporting >>>>>>>>>>>>>>>>>>>>>>>>>> Jakarta 9.0+, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with JDK-11 as the minimal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required JDK version (Jetty 11, >>>> ...) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andriy Redko JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 11, 2021 at 10:05 AM >>>>>>> Andriy >>>>>>>>>> Redko < drr...@gmail.com>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hey guys, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to initiate (or >>>> better to >>>>>>> say, >>>>>>>>>>>>>>> resume) the >>>>>>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> regarding CXF 3.5.x and beyond. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The 3.5.x has been in the making >>>> for >>>>>>> quite a >>>>>>>>>>>>>>> while but >>>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>>>>>>>>>> not seen >>>>>>>>>>>>>>>>>>>>>>>>>>>> any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases yet. As far as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I know, we have only pending >>>> upgrade to >>>>>>>>>> Apache >>>>>>>>>>>>>>> Karaf >>>>>>>>>>>>>>>>> 4.3.3 >>>>>>>>>>>>>>>>>>>>>>>>>> (on >>>>>>>>>>>>>>>>>>>>>>>>>>>> SNAPSHOT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> now) so be ready to meet >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JDK 17 LTS next month. I think >>>> this is >>>>>>> a good >>>>>>>>>>>>>>>>> opportunity >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3.5.0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but certainly looking >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for ideas and opinions here. >>>>>>> Importantly, I >>>>>>>>>>>> think >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> 3.5.x >>>>>>>>>>>>>>>>>>>>>>>>>> the JDK-8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be supported as the minimal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required JDK version (just an >>>> opinion >>>>>>> since >>>>>>>>>>>> JDK-8 >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>>>>>>>>>>>> widely >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On the other side, many libraries >>>>>>> (Jetty, >>>>>>>>>> wss4j, >>>>>>>>>>>>>>> ...) >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>>>> bumping the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseline to JDK-11. The work >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Colm is doing to update to >>>> OpenSaml >>>>>>> 4.x [1] >>>>>>>>>> is >>>>>>>>>>>> a >>>>>>>>>>>>>>> good >>>>>>>>>>>>>>>>>>>>>>>>>> argument to >>>>>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the JDK-11+ release line. Should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we have a dedicated 3.6.x or 4.x.x >>>>>>> branch(es) >>>>>>>>>>>> for >>>>>>>>>>>>>>> that? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Last but not least, Jakarta 9.0+ >>>>>>> support. >>>>>>>>>> Last >>>>>>>>>>>>>>> year we >>>>>>>>>>>>>>>>>>>>>>>>>> briefly talked >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about it [2], at this moment it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> looks like having dedicated >>>> release >>>>>>> line >>>>>>>>>>>> (4.x/5.x) >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>>>>> Jakarta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> artifacts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is beneficial in long term. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Large chunk [3] of work has been >>>>>>> already >>>>>>>>>> done in >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>> direction. The >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Spring 6 milestones with Jakarta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> support are expected to land in >>>>>>> Q4/2021 [4] >>>>>>>>>> but >>>>>>>>>>>> I >>>>>>>>>>>>>>> am >>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> sure what >>>>>>>>>>>>>>>>>>>>>>>>>>>> plans >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apache Karaf team has, @Freeman >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do you have any insights? JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For Jakarta EE9 support , the >>>> another >>>>>>> option >>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>>>>>>>>>>>>> adding a new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maven JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> module to transform cxf artifacts JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with jakarta package name. This >>>>>>> transformed >>>>>>>>>>>>>>> artifact >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>>>>>> coexist >>>>>>>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> javax namespace with "jakarta" >>>>>>> classifier, JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and we don't have to maintain two >>>>>>> branches >>>>>>>>>>>> until >>>>>>>>>>>>>>>>> Jakarta >>>>>>>>>>>>>>>>>>>>>>>>>> EE10 and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there are JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new features added. JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Other projects like hibernate and >>>>>>> jackson >>>>>>>>>> use >>>>>>>>>>>> this >>>>>>>>>>>>>>>>> shade >>>>>>>>>>>>>>>>>>>>>>>>>> plugin or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eclipse JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformer to support jakarta >>>> ee9: JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100 JM>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.xml#L115 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To summarize briefly: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - release 3.5.0 in preparation to >>>>>>> JDK-17 >>>>>>>>>> LTS, >>>>>>>>>>>>>>> keeping >>>>>>>>>>>>>>>>>>> JDK-8 >>>>>>>>>>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>> baseline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - move master to 3.6.x (4.x?) >>>> with >>>>>>> JDK-11 as >>>>>>>>>>>> the >>>>>>>>>>>>>>>>> minimal >>>>>>>>>>>>>>>>>>>>>>>>>> required >>>>>>>>>>>>>>>>>>>>>>>>>>>> JDK >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> version (Jetty 10, ...) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - branch off 5.x (4.x?) to >>>> continue >>>>>>> the >>>>>>>>>> work on >>>>>>>>>>>>>>>>>>> supporting >>>>>>>>>>>>>>>>>>>>>>>>>> Jakarta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 9.0+, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with JDK-11 as the minimal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required JDK version (Jetty >>>> 11, ...) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is very clear that >>>>>>> maintaining >>>>>>>>>>>> JavaEE + >>>>>>>>>>>>>>>>> JDK8 / >>>>>>>>>>>>>>>>>>>>>>>>>> JavaEE + >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JDK11 / >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jakarta + JDK11 would consume >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> much more time from the team, but >>>> I am >>>>>>> not >>>>>>>>>> sure >>>>>>>>>>>> we >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>>>>>>>>>>>> options if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we aim to evolve and keep CXF >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> up to date. Any thought, ideas, >>>>>>> comments, >>>>>>>>>>>>>>> suggestions >>>>>>>>>>>>>>>>>>> guys? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>> https://github.com/apache/cxf/tree/opensaml4 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2] >>>> http://mail-archives.apache.org/mod_mbox/cxf-dev/202012.mbox/%3c1503263798.20201226124...@gmail.com%3E >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3] >>>>>>> https://github.com/apache/cxf/pull/737 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [4] >>>> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andriy Redko
