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