Thanks for the quick update , Andriy. 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] I am not sure if I understood this issue correctly : we now use spring utility class to scan the resource/provider classes. If we make spring optional , this won't work and we have to create the Scanner like something with extcos ? >From looking at the code，it only used by load resource by non spring class. Would it be enough if we replace this with load resource from classloader ? @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). @Christian Do you still remember what's the main problem when you did this poc ? > > 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. > +1. Let's see how much we can move forward to reduce the scope of the spring dependency. I'll try to get more time to look at this task. > > 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 > >
