[GitHub] [cxf] mmoayyed opened a new pull request #833: CXF-8579: Switch JDK compiler to use JDK 11
mmoayyed opened a new pull request #833: URL: https://github.com/apache/cxf/pull/833 Avoid errors when building on JDK 11: ``` "[ERROR] /home/jitpack/build/rt/security-saml/src/main/java/org/apache/cxf/rt/security/saml/utils/SAMLUtils.java:[37,36] cannot access org.apache.wss4j.common.saml.SamlAssertionWrapper bad class file: /home/jitpack/.m2/repository/org/apache/wss4j/wss4j-ws-security-common/2.5.0-SNAPSHOT/wss4j-ws-security-common-2.5.0-SNAPSHOT.jar(org/apache/wss4j/common/saml/SamlAssertionWrapper.class) class file has wrong version 55.0, should be 52.0 Please remove or make sure it appears in the correct subdirectory of the classpath." ``` This PR is related to: https://issues.apache.org/jira/browse/CXF-8579 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] CXF 3.5.x and beyond
On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko 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? > For Jakarta EE9 support , the another option could be adding a new maven module to transform cxf artifacts with jakarta package name. This transformed artifact can coexist with the javax namespace with "jakarta" classifier, and we don't have to maintain two branches until Jakarta EE10 and there are new features added. Other projects like hibernate and jackson use this shade plugin or Eclipse transformer to support jakarta ee9: https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100 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 > >
Re: [DISCUSS] CXF 3.5.x and beyond
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, ...) 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 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
Re: [DISCUSS] CXF 3.5.x and beyond
Thanks for the summary Andriy, I like #3 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, ...) + maintaining 3.4.x for JDK-8 and security updates. Best, Dennis
Re: [DISCUSS] CXF 3.5.x and beyond
On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko 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 > I forgot to mention that I saw other projects with the transformation approach also transforming sources, javadoc jar and pom files with proper Eclipse transformer configuration. This can make it less confusing for users to debug and look at the api doc. > - 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, ...) > > 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 > 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
Re: [DISCUSS] CXF 3.5.x and beyond
Le mer. 11 août 2021 à 14:27, Andriy Redko a écrit : > 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 > Think maven shade plugin fixed that (and if you still find an issue it easier to fix it than handling 2 branches right?). > - Jakarta is the way to go, the mainstream should have first class support > This is compatible as explained. > > 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, ...) > Think 4/5 should stay for user features changes (like making cxf-core very slim and jaxrs way lighter and less monolitic to quote one I have in mind since years). Moving its major with no impact on end users is always weird IMHO. > > 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) +1 indeed ;) > > > 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 > 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
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Andriy, Thanks so much for your summary! I actually think we should support JDK8 as long as possible, given the fact that CXF is widely used, and some users are not that fast to adopt new JDK versions. Also CXF has started to support JDK11(even more recent JDK versions) for a while, so any keen users can still use CXF with JDK11+(I noticed many users' JDK is JDK11+ from Jira issues). So how about this(a little bit revised from your option 1) Release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline, and in CXF 3.5.0 release notes we need to very clearly declare that since CXF 3.6.0 users should expect JDK-11 as baseline(Or at least JDK-11 would be the primary, and JDK-8 would be the secondary, just like what the latest Apache Camel 3.X does). Move master to 3.6.x with JDK-11 as the baseline. New CXF 4.x branch for new jakarta package name work(whatever methods need to take there), this change definitely deserves a new major version. Best Regards Freeman On Wed, Aug 11, 2021 at 8:27 AM Andriy Redko 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, ...) > > 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 > 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-prov
Re: [DISCUSS] CXF 3.5.x and beyond
Thanks a lot Feeman, this is basically the Option #1, or you suggest to stay on JDK-8 for Jakarta 4.x branch as well? Thank you. Best Regards, Andriy Redko On Wed, Aug 11, 2021, 10:10 AM Freeman Fang wrote: > Hi Andriy, > > Thanks so much for your summary! > > I actually think we should support JDK8 as long as possible, given the > fact that CXF is widely used, and some users are not that fast to adopt new > JDK versions. Also CXF has started to support JDK11(even more recent JDK > versions) for a while, so any keen users can still use CXF with JDK11+(I > noticed many users' JDK is JDK11+ from Jira issues). So how about this(a > little bit revised from your option 1) > > Release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline, and > in CXF 3.5.0 release notes we need to very clearly declare that since CXF > 3.6.0 users should expect JDK-11 as baseline(Or at least JDK-11 would be > the primary, and JDK-8 would be the secondary, just like what the latest > Apache Camel 3.X does). > > Move master to 3.6.x with JDK-11 as the baseline. > > New CXF 4.x branch for new jakarta package name work(whatever methods need > to take there), this change definitely deserves a new major version. > > Best Regards > Freeman > > > > > On Wed, Aug 11, 2021 at 8:27 AM Andriy Redko 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, ...) >> >> 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 >> 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 un
Re: [DISCUSS] CXF 3.5.x and beyond
Sorry for not being very clear. No, for Jakarta 4.x branch we definitely can move to JDK11. Thanks! Freeman On Wed, Aug 11, 2021 at 11:05 AM Andrey Redko wrote: > Thanks a lot Feeman, this is basically the Option #1, or you suggest to > stay on JDK-8 for Jakarta 4.x branch as well? Thank you. > > Best Regards, > Andriy Redko > > On Wed, Aug 11, 2021, 10:10 AM Freeman Fang > wrote: > >> Hi Andriy, >> >> Thanks so much for your summary! >> >> I actually think we should support JDK8 as long as possible, given the >> fact that CXF is widely used, and some users are not that fast to adopt new >> JDK versions. Also CXF has started to support JDK11(even more recent JDK >> versions) for a while, so any keen users can still use CXF with JDK11+(I >> noticed many users' JDK is JDK11+ from Jira issues). So how about this(a >> little bit revised from your option 1) >> >> Release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline, >> and in CXF 3.5.0 release notes we need to very clearly declare that since >> CXF 3.6.0 users should expect JDK-11 as baseline(Or at least JDK-11 would >> be the primary, and JDK-8 would be the secondary, just like what the latest >> Apache Camel 3.X does). >> >> Move master to 3.6.x with JDK-11 as the baseline. >> >> New CXF 4.x branch for new jakarta package name work(whatever methods >> need to take there), this change definitely deserves a new major version. >> >> Best Regards >> Freeman >> >> >> >> >> On Wed, Aug 11, 2021 at 8:27 AM Andriy Redko 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, ...) >>> >>> 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 >>> 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? >>> >>> >>>
Re: [DISCUSS] CXF 3.5.x and beyond
Awesome, so this is Option #1, thank you! Best Regards, Andriy Redko On Wed, Aug 11, 2021, 11:13 AM Freeman Fang wrote: > Sorry for not being very clear. > > No, for Jakarta 4.x branch we definitely can move to JDK11. > > Thanks! > Freeman > > On Wed, Aug 11, 2021 at 11:05 AM Andrey Redko wrote: > >> Thanks a lot Feeman, this is basically the Option #1, or you suggest to >> stay on JDK-8 for Jakarta 4.x branch as well? Thank you. >> >> Best Regards, >> Andriy Redko >> >> On Wed, Aug 11, 2021, 10:10 AM Freeman Fang >> wrote: >> >>> Hi Andriy, >>> >>> Thanks so much for your summary! >>> >>> I actually think we should support JDK8 as long as possible, given the >>> fact that CXF is widely used, and some users are not that fast to adopt new >>> JDK versions. Also CXF has started to support JDK11(even more recent JDK >>> versions) for a while, so any keen users can still use CXF with JDK11+(I >>> noticed many users' JDK is JDK11+ from Jira issues). So how about this(a >>> little bit revised from your option 1) >>> >>> Release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline, >>> and in CXF 3.5.0 release notes we need to very clearly declare that since >>> CXF 3.6.0 users should expect JDK-11 as baseline(Or at least JDK-11 would >>> be the primary, and JDK-8 would be the secondary, just like what the latest >>> Apache Camel 3.X does). >>> >>> Move master to 3.6.x with JDK-11 as the baseline. >>> >>> New CXF 4.x branch for new jakarta package name work(whatever methods >>> need to take there), this change definitely deserves a new major version. >>> >>> Best Regards >>> Freeman >>> >>> >>> >>> >>> On Wed, Aug 11, 2021 at 8:27 AM Andriy Redko 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, ...) 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 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 chu
Re: [DISCUSS] CXF 3.5.x and beyond
I’m very strongly in favor of Option #1 at this point, with a “release note” mentioning that 3.5.x will be the last series to support Java8. I know we have plenty of services running with Java8 and have several customers that are still targeting Java8. I really think we need to keep Java8 as an option at this point, but let folks know that it will be changing. Dan > On Aug 11, 2021, at 8:26 AM, Andriy Redko 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, ...) > > 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 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 t
