I will check it out shortly, thanks a lot Jim!
Best Regards,
Andriy Redko
JM> @Andriy, I finally get time to back on this task. I just sent a PR as you
JM> suggested : https://github.com/apache/cxf/pull/855
JM> and labeled it with "work-in-progress".
JM> If anyone has any idea to improve this, feel free to comment, update or
JM> replace it with another PR.
JM> Thanks,
JM> Jim
JM> On Wed, Sep 8, 2021 at 8:55 AM Jim Ma <mail2ji...@gmail.com> wrote:
>> On Tue, Sep 7, 2021 at 4:56 AM Andriy Redko <drr...@gmail.com> wrote:
>>> Hey Jim,
>>> No, we don't have a branch just yet, primarily because we depend on the
>>> few
>>> snapshots in 3.5.0/master.
>>> @Colm do you have an idea regarding xmlschema 2.3.0 release timelines?
>>> @Dan do you have an idea regarding neethi 3.2.0 release timelines?
>>> At worst, you could create a new branch for this feature, or submit a
>>> pull request against master which we should be able to re-target later
>>> against the right branch (should be easy). What do you think?
>> This is a good idea. I'll send a PR against the master, and later we can
>> decide the place to merge.
>> Thanks, Andriy.
>>> Best Regards,
>>> Andriy Redko
>>> JM> Thanks for more updates , Andriy.
>>> JM> Is there a place/workspace branch, I can send a PR for this change?
>>> JM> On Fri, Sep 3, 2021 at 9:20 PM Andriy Redko <drr...@gmail.com> wrote:
>>> >> Hey Jim,
>>> >> Thanks a lot for taking the lead on this one. Just want to chime in on
>>> a
>>> >> few points. Indeed, as
>>> >> per previous discussion in this thread, it seems like it make sense to
>>> >> provide only the subset
>>> >> of shaded modules with Jakarta namespace. Also, it was confirmed
>>> yesterday
>>> >> that Spring Framework
>>> >> 6 milestones will be available in November this year but the first
>>> >> snapshots will be out in late
>>> >> September / early October, looks pretty promising. One **unexpected**
>>> part
>>> >> of the announcement
>>> >> is JDK17 baseline for Spring Framework & Co, that could be a bummer
>>> but I
>>> >> have the feeling that
>>> >> it will be lowered to JDK11. Thank you.
>>> >> Best Regards,
>>> >> Andriy Redko
>>> >> JM> Good point, Romain. We need to look at what to do to make sure all
>>> >> JM> artifacts are included and transformed if this becomes a cxf
>>> module.
>>> >> JM> BTW, Spring 6 GA supports jakarta ee9 will come in Q4 2022 :
>>> >> JM>
>>> >>
>>> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>>> >> JM> On Fri, Sep 3, 2021 at 6:20 PM Romain Manni-Bucau <
>>> >> rmannibu...@gmail.com>
>>> >> JM> wrote:
>>> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <mail2ji...@gmail.com> a
>>> écrit :
>>> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>>> >> rmannibu...@gmail.com>
>>> >> >>> wrote:
>>> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <mail2ji...@gmail.com> a
>>> écrit :
>>> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>>> >> >>>>> rmannibu...@gmail.com> wrote:
>>> >> >>>>>> 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.
>>> >> >>>>> I agree to start with something to preview and collect more
>>> ideas to
>>> >> >>>>> support ee9. It's good to have a branch to really start something
>>> >> for this
>>> >> >>>>> topic.
>>> >> >>>>> @Romain, do you have a prototype with shading or other tools for
>>> a
>>> >> >>>>> jakarta jaxrs bundle or just some basic idea that we can have a
>>> look
>>> >> at ?
>>> >> >>>> Not ready for cxf but looking at meecrowave-core pom you would
>>> have
>>> >> some
>>> >> >>>> idea.
>>> >> >>>> I just suspect pom deps need some refinement like with/without the
>>> >> >>>> client (it is useless with java 11 now and less and less desired
>>> >> AFAIK).
>>> >> >>> @Romain Manni-Bucau <rmannibu...@gmail.com> Thanks for the
>>> update. I
>>> >> >>> looked at the meecrowave-core pom and understood how it transforms
>>> >> package
>>> >> >>> names with the shade plugin. Both shade plugin or eclipse
>>> transformer
>>> >> tool
>>> >> >>> works for this purpose .
>>> >> >>> I created one prototype project which pulls in cxf dependencies,
>>> >> >>> transforms to jakarta namespace and installs to local maven
>>> >> repository :
>>> >> >>> https://github.com/jimma/cxf-ee9-transformer
>>> >> >>> This doesn't need more effort and no need the code/dependency
>>> change
>>> >> >>> which breaks/mixes with javax support codebase. It can be simply
>>> added
>>> >> with
>>> >> >>> another maven module in cxf repo to produce transformed jakata cxf
>>> >> >>> artifacts or binary distribution. Your thoughts ?
>>> >> >> If not all artifacts are proposed with jakarta support it is an
>>> option
>>> >> >> otherwise it would need a build module to synchronize this
>>> submodule(s)
>>> >> to
>>> >> >> ensure none are forgotten - this is where I prefer the classifier
>>> >> approach
>>> >> >> even if it has this exclusion pitfalls - but cxf has it anyway due
>>> to
>>> >> its
>>> >> >> transitive dependencies so not worse IMHO ;).
>>> >> >>>>> Thanks,
>>> >> >>>>> Jim
>>> >> >>>>>>> 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
