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

-- 
Daniel Kulp
dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog 
<http://dankulp.com/blog>
Talend - http://talend.com <http://coders.talend.com/>

Reply via email to