Hi Andriy, >From what I looked at last time, it seems it's difficult to decouple these osgi/karaf integration code from cxf core and create a new project to put it into a separate repository. IMO, we can create a branch before we remove these integration codes, and later we can look at this branch to restore the osgi/integration code when osgi jakarta support is available. Your thoughts?
Thanks, Jim On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko <drr...@gmail.com> wrote: > 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 > >
