Thanks for more updates , Andriy. Is there a place/workspace branch, I can send a PR for this change?
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 > > >
