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