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