Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko]

Hi Jim,

That is correct, I am working on https://issues.apache.org/jira/browse/CXF-8717 
as part of
Jetty 11 migration, the Atmosphere implementation seems to be fine. Thanks.

Best Regards,
    Andriy Redko


JM> Thanks for the update, Andiry. You already did a lot of work on third party
JM> jakarta support !

JM> Just to understand the CXF Jakarta support work status, are these issues we
JM> can start without waiting for the dependency release ?
JM> https://issues.apache.org/jira/browse/CXF-8716
JM> https://issues.apache.org/jira/browse/CXF-8717
JM> https://issues.apache.org/jira/browse/CXF-8719



JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <drr...@gmail.com> wrote:

>> Hi Jim,
>>
>> Yeah, we may need some time, I am also finalizing work on the Wiremock (
>> https://github.com/wiremock/wiremock/pull/1942),
>> we use it in tests extensively. One of the largest efforts is migration to
>> Jetty 11, I have started on that already but
>> have difficulties with WebSockets migration, it needs rework and that is
>> my focus at the moment. The Swagger 1.x we have
>> to drop I believe, I don't see roadmap on Jakarta support there.
>>
>> Thanks!
>>
>> Best Regards,
>>     Andriy Redko
>>
>> JM> Hi Andriy,
>> JM> It looks like we still have to wait for the other dependency jakarta
>> JM> support available, like brave's new release to include this change :
>> JM> https://github.com/openzipkin/brave/pull/1344.  Do you see any other
>> JM> dependencies that haven't been released yet except OSGI and Karaf ?
>>
>> JM> Thanks,
>> JM> Jim
>>
>>
>> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> wrote:
>>
>> >> Thanks for the informative input, Freeman.
>> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good
>> >> chance to do this job. When OSGI/Karaf jakarta release is ready,
>> >> We can look at bringing this back with more improvement and refactor
>> work
>> >> to make it loosely coupled with core code.
>> >>
>> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang <freeman.f...@gmail.com>
>> >> wrote:
>> >>
>> >>> Hi Jim,
>> >>>
>> >>> Sorry for the late reply, just back from vacation.
>> >>>
>> >>> About the OSGi part, the main problem is that the OSGi R9 spec which
>> will
>> >>> support Jakarta namespace is in progress and isn't released yet(and I
>> don't
>> >>> think there is a concrete release date for OSGi R9 spec in the new
>> future).
>> >>> Before OSGi R9 spec gets released and adopted by OSGi implementations
>> like
>> >>> Felix/Equinox, I don't think there is much we can do in CXF or even in
>> >>> Karaf about this part.
>> >>>
>> >>> And Andriy, you are right,  release CXF 4.0 M1 without OSGi/Karaf bit
>> >>> seems the only option we have so far,  and I'm +1 for this way
>> now(Since we
>> >>> don't know how long we need to wait for the proper OSGi spec released
>> and
>> >>> upstream projects can support it).
>> >>>
>> >>> Just my 2 cents.
>> >>> Best Regards
>> >>> Freeman
>> >>>
>> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> wrote:
>> >>>
>> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman
>> >>>> about this topic several months ago and got to know
>> >>>> there won't be Jakarta namespace support work in the future. I don't
>> >>>> know if this has changed.
>> >>>> Freeman, do you have some update on this ?
>> >>>>
>> >>>>
>> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> 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
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>>
>> >>>>> >>>
>> >>>>>
>> >>>>>
>> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> wrote:
>>
>> >> Thanks for the informative input, Freeman.
>> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good
>> >> chance to do this job. When OSGI/Karaf jakarta release is ready,
>> >> We can look at bringing this back with more improvement and refactor
>> work
>> >> to make it loosely coupled with core code.
>> >>
>> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang <freeman.f...@gmail.com>
>> >> wrote:
>> >>
>> >>> Hi Jim,
>> >>>
>> >>> Sorry for the late reply, just back from vacation.
>> >>>
>> >>> About the OSGi part, the main problem is that the OSGi R9 spec which
>> will
>> >>> support Jakarta namespace is in progress and isn't released yet(and I
>> don't
>> >>> think there is a concrete release date for OSGi R9 spec in the new
>> future).
>> >>> Before OSGi R9 spec gets released and adopted by OSGi implementations
>> like
>> >>> Felix/Equinox, I don't think there is much we can do in CXF or even in
>> >>> Karaf about this part.
>> >>>
>> >>> And Andriy, you are right,  release CXF 4.0 M1 without OSGi/Karaf bit
>> >>> seems the only option we have so far,  and I'm +1 for this way
>> now(Since we
>> >>> don't know how long we need to wait for the proper OSGi spec released
>> and
>> >>> upstream projects can support it).
>> >>>
>> >>> Just my 2 cents.
>> >>> Best Regards
>> >>> Freeman
>> >>>
>> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> wrote:
>> >>>
>> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman
>> >>>> about this topic several months ago and got to know
>> >>>> there won't be Jakarta namespace support work in the future. I don't
>> >>>> know if this has changed.
>> >>>> Freeman, do you have some update on this ?
>> >>>>
>> >>>>
>> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> 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
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>>
>> >>>>> >>>
>> >>>>>
>> >>>>>
>>
>>