Hey Jim,
I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real blockers.
For Swagger 1.x, we could
go ahead and drop the support altogether, this is quite isolated feature. OSGi
and Karaf are not, those
penetrated very deep into core. What worries me, if we drop everything
OSGi/Karaf related from 4.0.0, we
may need to bring it back some time in the future (with OSGi R9 [4] fe) and
that is going to be quite
difficult. From other side, this is probably the only option to have 4.0.0
milestone out (we excluded some
modules from the build right now but that is more like a temporary hack which
we should not release upon,
even alphas). What do you think guys?
Best Regards,
Andriy Redko
[1] https://issues.apache.org/jira/browse/CXF-8714
[2] https://issues.apache.org/jira/browse/CXF-8723
[3] https://issues.apache.org/jira/browse/CXF-8722
[4] https://github.com/osgi/osgi/milestone/5
JM> After we merged the jakarta branch to default branch main branch, do we
JM> need to create some
JM> plan to do a future 4.x release?
JM> There are a couple of to-do things under
JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla,
JM> and for some of them we can't do more things because of the jakarta
JM> dependency missing. It seems that some of the dependencies won't
JM> have the jakarta namespace artifact released in the near future. Should we
JM> have some milestone/alpha release
JM> before all these dependencies are available ? And if we want to do a
JM> milestone release, what do you think we should have in
JM> this 4.0.0-M1 release ?
JM> Thanks,
JM> Jim
JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma <mail2ji...@gmail.com> wrote:
>> Thanks Andriy too for driving this and moving forward !
>>
>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <drr...@gmail.com> wrote:
>>
>>> Hey guys,
>>>
>>> The Jakarta branch [1] just went into master, HUGE THANKS everyone for
>>> tremendous effort! Please
>>> note, it is still work in progress, the things to be done are tracked
>>> under [2], feel free to
>>> add more items or pick the existing ones. The master builds still have
>>> some tests failing, but those
>>> should be fixed shortly. With that, 3.6.x-fixes becomes the "mirror" of
>>> the master but for javax.*
>>> packages. Cherrypicking / backporting changes from master might be a bit
>>> more complicated (jakarta.* -> javax.*)
>>> but manageable.
>>>
>>> One more thing, the pull requests against master and 3.6.x / 3.5.x are
>>> build using JDK-17 now (was JDK-11
>>> before), this is due to the fact that master needs JDK-17, as it's Spring
>>> 6 / Spring Boot 3 JDK baseline.
>>> I have difficulties configuring Jenkins Maven builds + Github Pull
>>> Request builder per branch. It may be
>>> possible with pipeline, I will experiment with that. Please share any
>>> concerns, comments or feedback, it
>>> is highly appreciated.
>>>
>>> Thank you!
>>>
>>> [1] https://github.com/apache/cxf/pull/912
>>> [2] https://issues.apache.org/jira/browse/CXF-8371
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> COh> +1 from me.
>>>
>>> COh> Colm.
>>>
>>> COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma <mail2ji...@gmail.com> wrote:
>>> >>
>>> >> Hi Andriy,
>>> >> A good plan. I agree with all these changes and support versions.
>>> >>
>>> >> Thanks,
>>> >> Jim
>>> >>
>>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko <drr...@gmail.com>
>>> wrote:
>>> >>
>>> >> > Hey folks,
>>> >> >
>>> >> > While the work on 4.x / Jakarta is slowly but steadily moving
>>> forward, it
>>> >> > is
>>> >> > time to think about next 3.x release line. As we discussed in this
>>> thread,
>>> >> > it
>>> >> > seems we agreed on 3.6.x to be next javax.* based release, with
>>> JDK-11 as
>>> >> > the
>>> >> > baseline. We have new Spring Boot 2.7.0 just released [1], along
>>> with tons
>>> >> > of other
>>> >> > related projects. I would like to propose to:
>>> >> > - branch off 3.6.x-fixes (from master) and work on upgrades (+ some
>>> new
>>> >> > features)
>>> >> > - as per @Jim suggestion, merge (very soon) Jakarta branch [2] into
>>> master
>>> >> >
>>> >> > From the support perspective, it means we would need to maintain
>>> 3.4.x for
>>> >> > some
>>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at some point).
>>> What do
>>> >> > you
>>> >> > think guys? Thank you!
>>> >> >
>>> >> > [1]
>>> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now
>>> >> > [2] https://github.com/apache/cxf/pull/912
>>> >> >
>>> >> > Best Regards,
>>> >> > Andriy Redko
>>> >> >
>>> >> >
>>> >> > JM> Hi Andriy,
>>> >> > JM> I took some time to look at the CXF java11 support and spring
>>> >> > decoupling
>>> >> > JM> last week.
>>> >> > JM> Here are some thoughts and initial work:
>>> >> > JM> 1) Use cross compile to support java11 . We can simply change
>>> >> > JM> <cxf.jdk.version> in pom.xml to 11.
>>> >> > JM> This will allow the maven compiler plugin to build cxf with
>>> java11.
>>> >> > JM> 2) We can look at creating some separate modules for Spring
>>> relevant
>>> >> > JM> code/configuration in the future. Ideally a small
>>> >> > JM> number of modules would be better and it will make it easy for
>>> users
>>> >> > to
>>> >> > JM> import spring relevant dependencies.
>>> >> > JM> Here is my initial work :
>>> >> > https://github.com/jimma/cxf/commits/spring
>>> >> > JM> <https://github.com/jimma/cxf/commits/spring>. This only touches
>>> >> > several
>>> >> > JM> cxf modules, I am not
>>> >> > JM> sure if this approach will get other blockers and issues.
>>> >> >
>>> >> > JM> Thanks,
>>> >> > JM> Jim
>>> >> >
>>> >> >
>>> >> >
>>> >> > JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <drr...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> > >> Hey Jim,
>>> >> >
>>> >> > >> AFAIR this particular topic has popped up several times, a few
>>> issues
>>> >> > >> exist [1] and
>>> >> > >> @Christian even did the POC several years ago [2] in attempt to
>>> remove
>>> >> > >> some of the
>>> >> > >> hard Spring dependencies (I don't know the outcomes to be fair
>>> but I
>>> >> > >> suspect it turned
>>> >> > >> out to be much more difficult than anticipated).
>>> >> >
>>> >> > >> The suggestion I have in mind is to keep JDK-17 baseline **for
>>> now** and
>>> >> > >> continue working
>>> >> > >> on addressing the blockers (there too many at this point). Once
>>> we get
>>> >> > to
>>> >> > >> the state when
>>> >> > >> the Jakarta branch is at least buildable / deployable, we could
>>> reassess
>>> >> > >> the Spring
>>> >> > >> coupling. I am just afraid doing everything at once would
>>> introduce
>>> >> > >> instability in
>>> >> > >> codebase and slow down everyone on either of these efforts. Not
>>> sure if
>>> >> > >> you agree but
>>> >> > >> in any case I am definitely +1 for reducing the scope of
>>> dependencies on
>>> >> > >> Spring, even
>>> >> > >> in 3.4.x / 3.5.x release lines.
>>> >> >
>>> >> > >> Thank you.
>>> >> >
>>> >> > >> [1] https://issues.apache.org/jira/browse/CXF-5477
>>> >> > >> [2] https://github.com/apache/cxf/tree/poc-remove-spring-bp
>>> >> >
>>> >> > >> Best Regards,
>>> >> > >> Andriy Redko
>>> >> >
>>> >> > >> JM> I accidentally clicked the send button, please ignore my
>>> previous
>>> >> > >> email
>>> >> > >> JM> and look at this reply.
>>> >> >
>>> >> > >> JM> On Sat, Jan 29, 2022 at 7:58 PM Jim Ma <mail2ji...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>> drr...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> > >> >>> Hey guys,
>>> >> >
>>> >> > >> >>> A bunch of good things have happened at the end of this year.
>>> The
>>> >> > 3.5.0
>>> >> > >> >>> out and we are in a good
>>> >> > >> >>> shape to kick off Jakarta support: the Spring 6 milestones and
>>> >> > Spring
>>> >> > >> >>> Boot 3 snapshots are already
>>> >> > >> >>> available. There are tons of things to fix and address, I have
>>> >> > created
>>> >> > >> >>> this draft pull request [1]
>>> >> > >> >>> with a first batch of changes and TODOs. Everyone should be
>>> able to
>>> >> > >> push
>>> >> > >> >>> changes in there, if not
>>> >> > >> >>> - please let me know, I could give perms / move the branch to
>>> CXF
>>> >> > >> Github
>>> >> > >> >>> repo. Hope in the next
>>> >> > >> >>> couple of months we get closer to fully embrace Jakarta.
>>> >> >
>>> >> > >> >>> On the not so good news side, Spring 6 has kept JDK-17
>>> baseline. It
>>> >> > >> does
>>> >> > >> >>> not play well with our
>>> >> > >> >>> original plan to stick to JDK-11 baseline for 4.x but I am
>>> not sure
>>> >> > we
>>> >> > >> >>> have any choice here besides
>>> >> > >> >>> bumping the baseline as well.
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> JM> From the JakartaEE9 release[1]and JakartaEE10 plan[2], it
>>> still
>>> >> > >> needs to
>>> >> > >> JM> support JDK11. Jakarta Restful WebService 3.0/3.1 and
>>> Jakarta XML
>>> >> > Web
>>> >> > >> JM> Services 3.0/3.1
>>> >> > >> JM> apis are the specifications we need to implement in CXF, so
>>> we
>>> >> > need
>>> >> > >> to
>>> >> > >> JM> build, run and test implementation with JDK11.
>>> >> >
>>> >> > >> JM> Just thinking this loud, is it possible that we make Spring
>>> >> > plugable
>>> >> > >> or
>>> >> > >> JM> really optional ? 4.x is the major release and it's the
>>> chance
>>> >> > >> JM> to refactor CXF code(like we move spring related
>>> source/test to
>>> >> > >> separate
>>> >> > >> JM> module) to build/run/test without Spring with a maven profile.
>>> >> >
>>> >> > >> JM> [1]
>>> >> > >> JM>
>>> >> > >>
>>> >> >
>>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
>>> >> > >> JM> [2]
>>> >> > >> JM>
>>> >> > >>
>>> >> >
>>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> Happy Holidays guys!
>>> >> >
>>> >> > >> >>> [1] https://github.com/apache/cxf/pull/888
>>> >> >
>>> >> > >> >>> JM> 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?
>>> >> >
>>> >> >
>>> >> > >> >>> JM> This is a good idea. I'll send a PR against the master,
>>> and
>>> >> > later
>>> >> > >> we
>>> >> > >> >>> can
>>> >> > >> >>> JM> decide the place to merge.
>>> >> > >> >>> JM> 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
>>> >> >
>>> >> >
>>>
>>>
