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 > >>> >> > > >>> >> > > >>> > >>> > >
