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
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>>
>>>>> >>>
>>>>>
>>>>>
