Hi Colm,
Thank you, for 3.5.0, we are waiting for Apache Karaf 4.3.3 to be released
so you definitely have time. I think ideally, it would be great to have 3.5.0
in September, how does it look from your perspective? Certainly +1 to phase out
3.3.x release line. Thank you.
Best Regards,
Andriy Redko
COh> Hi,
COh> I don't have strong views either way, but it seems like the majority
COh> favour having one more release of CXF with JDK 8 support. Andriy, when
COh> do you anticipate we could release CXF 3.5.0 by? I need to release new
COh> major versions of Santuario + WSS4J first, but there is not a huge
COh> amount of work involved. I would also like to drop CXF 3.3.x at the
COh> same time to reduce the maintenance burden on us.
COh> Colm.
COh> On Tue, Aug 17, 2021 at 6:39 AM Romain Manni-Bucau
COh> <rmannibu...@gmail.com> wrote:
>> I'm not sure I see why you need spring to start this work. The expected is
>> there already so spring module can still rely on javax, be made jakarta
>> friendly using shade plugin or alike and that's it until a spring native
>> integration is there.
>> Worse case cxf-spring will not be usable with jakarta - which still enabled
>> all other usages, best case if spring makes the transition smooth is that
>> it will work smoothly without more investment than for the rest of the
>> build.
>> The pro of that options is that it will reduce the number of unofficial cxf
>> relocations sooner IMHO.
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
>> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>> 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
>> >
>> >
