+1 from me. Colm.
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 > > > >
