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. From the JakartaEE10 release plan[1], it still needs to support JDK11. Jakarta Restful Webservice 3.1 and Jakarta XML Web Services 4.0. Just thinking this loud, is it possible that we make Spring plugable ? In [1] 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 > >
