Awesome, so this is Option #1, thank you!
Best Regards,
Andriy Redko
On Wed, Aug 11, 2021, 11:13 AM Freeman Fang <freeman.f...@gmail.com> 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 <drr...@gmail.com> 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 <freeman.f...@gmail.com>
>> 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 <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
>>>>
>>>>
