Hi Jim,
No objections from my side, thank you.
Best Regards,
Andriy Redko
On Tue, Sep 27, 2022, 9:31 PM Jim Ma <mail2ji...@gmail.com> wrote:
> Hi all,
> If there is no objection, I will create a branch "osgi-pre-removal-v4.0"
> to record the changes before the osgi and karaf removal, then
> merge the this PR https://github.com/apache/cxf/pull/999 to the main
> branch.
>
> Thanks,
> Jim
>
> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko <drr...@gmail.com> wrote:
>
>> This is great, thanks Jim, I will also take a look shortly. Thanks!
>>
>> Best Regards,
>> Andriy Redko
>>
>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma <mail2ji...@gmail.com> wrote:
>>
>>> Hi All,
>>> I tried to remove the osgi and karaf from CXF with this draft PR :
>>> https://github.com/apache/cxf/pull/999
>>> <https://github.com/apache/cxf/pull/999>.
>>> This mainly removed the osgi code,test, examples and dependency, but for
>>> some class like SpringBus which deeply coupled with osgi:
>>>
>>> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142
>>> <https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142>
>>> I added the comment "//uncomment this when osgi comes back" to mark
>>> these commented lines for osgi. With the branch created before
>>> this change is merged to main, I am sure this will make it easy to bring
>>> the osgi and karaf back when the Jakarta support is ready in the future.
>>>
>>> Please help review this PR. If you have any comment or question, please
>>> let me know.
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>> On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko <drr...@gmail.com> wrote:
>>>
>>>> Hi Jim,
>>>>
>>>> That is correct, I am working on
>>>> https://issues.apache.org/jira/browse/CXF-8717 as part of
>>>> Jetty 11 migration, the Atmosphere implementation seems to be fine.
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>>
>>>> JM> Thanks for the update, Andiry. You already did a lot of work on
>>>> third party
>>>> JM> jakarta support !
>>>>
>>>> JM> Just to understand the CXF Jakarta support work status, are these
>>>> issues we
>>>> JM> can start without waiting for the dependency release ?
>>>> JM> https://issues.apache.org/jira/browse/CXF-8716
>>>> JM> https://issues.apache.org/jira/browse/CXF-8717
>>>> JM> https://issues.apache.org/jira/browse/CXF-8719
>>>>
>>>>
>>>>
>>>> JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <drr...@gmail.com>
>>>> wrote:
>>>>
>>>> >> Hi Jim,
>>>> >>
>>>> >> Yeah, we may need some time, I am also finalizing work on the
>>>> Wiremock (
>>>> >> https://github.com/wiremock/wiremock/pull/1942),
>>>> >> we use it in tests extensively. One of the largest efforts is
>>>> migration to
>>>> >> Jetty 11, I have started on that already but
>>>> >> have difficulties with WebSockets migration, it needs rework and
>>>> that is
>>>> >> my focus at the moment. The Swagger 1.x we have
>>>> >> to drop I believe, I don't see roadmap on Jakarta support there.
>>>> >>
>>>> >> Thanks!
>>>> >>
>>>> >> Best Regards,
>>>> >> Andriy Redko
>>>> >>
>>>> >> JM> Hi Andriy,
>>>> >> JM> It looks like we still have to wait for the other dependency
>>>> jakarta
>>>> >> JM> support available, like brave's new release to include this
>>>> change :
>>>> >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see any
>>>> other
>>>> >> JM> dependencies that haven't been released yet except OSGI and
>>>> Karaf ?
>>>> >>
>>>> >> JM> Thanks,
>>>> >> JM> Jim
>>>> >>
>>>> >>
>>>> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> >> Thanks for the informative input, Freeman.
>>>> >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is
>>>> a good
>>>> >> >> chance to do this job. When OSGI/Karaf jakarta release is ready,
>>>> >> >> We can look at bringing this back with more improvement and
>>>> refactor
>>>> >> work
>>>> >> >> to make it loosely coupled with core code.
>>>> >> >>
>>>> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang <
>>>> freeman.f...@gmail.com>
>>>> >> >> wrote:
>>>> >> >>
>>>> >> >>> Hi Jim,
>>>> >> >>>
>>>> >> >>> Sorry for the late reply, just back from vacation.
>>>> >> >>>
>>>> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec
>>>> which
>>>> >> will
>>>> >> >>> support Jakarta namespace is in progress and isn't released
>>>> yet(and I
>>>> >> don't
>>>> >> >>> think there is a concrete release date for OSGi R9 spec in the
>>>> new
>>>> >> future).
>>>> >> >>> Before OSGi R9 spec gets released and adopted by OSGi
>>>> implementations
>>>> >> like
>>>> >> >>> Felix/Equinox, I don't think there is much we can do in CXF or
>>>> even in
>>>> >> >>> Karaf about this part.
>>>> >> >>>
>>>> >> >>> And Andriy, you are right, release CXF 4.0 M1 without
>>>> OSGi/Karaf bit
>>>> >> >>> seems the only option we have so far, and I'm +1 for this way
>>>> >> now(Since we
>>>> >> >>> don't know how long we need to wait for the proper OSGi spec
>>>> released
>>>> >> and
>>>> >> >>> upstream projects can support it).
>>>> >> >>>
>>>> >> >>> Just my 2 cents.
>>>> >> >>> Best Regards
>>>> >> >>> Freeman
>>>> >> >>>
>>>> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com>
>>>> wrote:
>>>> >> >>>
>>>> >> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with
>>>> Freeman
>>>> >> >>>> about this topic several months ago and got to know
>>>> >> >>>> there won't be Jakarta namespace support work in the future. I
>>>> don't
>>>> >> >>>> know if this has changed.
>>>> >> >>>> Freeman, do you have some update on this ?
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko <drr...@gmail.com>
>>>> >> wrote:
>>>> >> >>>>
>>>> >> >>>>> Hey Jim,
>>>> >> >>>>>
>>>> >> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are
>>>> real
>>>> >> >>>>> blockers. For Swagger 1.x, we could
>>>> >> >>>>> go ahead and drop the support altogether, this is quite
>>>> isolated
>>>> >> >>>>> feature. OSGi and Karaf are not, those
>>>> >> >>>>> penetrated very deep into core. What worries me, if we drop
>>>> >> everything
>>>> >> >>>>> OSGi/Karaf related from 4.0.0, we
>>>> >> >>>>> may need to bring it back some time in the future (with OSGi
>>>> R9 [4]
>>>> >> fe)
>>>> >> >>>>> and that is going to be quite
>>>> >> >>>>> difficult. From other side, this is probably the only option
>>>> to have
>>>> >> >>>>> 4.0.0 milestone out (we excluded some
>>>> >> >>>>> modules from the build right now but that is more like a
>>>> temporary
>>>> >> hack
>>>> >> >>>>> which we should not release upon,
>>>> >> >>>>> even alphas). What do you think guys?
>>>> >> >>>>>
>>>> >> >>>>> Best Regards,
>>>> >> >>>>> Andriy Redko
>>>> >> >>>>>
>>>> >> >>>>> [1] https://issues.apache.org/jira/browse/CXF-8714
>>>> >> >>>>> [2] https://issues.apache.org/jira/browse/CXF-8723
>>>> >> >>>>> [3] https://issues.apache.org/jira/browse/CXF-8722
>>>> >> >>>>> [4] https://github.com/osgi/osgi/milestone/5
>>>> >> >>>>>
>>>> >> >>>>> JM> After we merged the jakarta branch to default branch main
>>>> branch,
>>>> >> >>>>> do we
>>>> >> >>>>> JM> need to create some
>>>> >> >>>>> JM> plan to do a future 4.x release?
>>>> >> >>>>>
>>>> >> >>>>> JM> There are a couple of to-do things under
>>>> >> >>>>> JM> https://issues.apache.org/jira/browse/CXF-8371
>>>> umberbralla,
>>>> >> >>>>> JM> and for some of them we can't do more things because of the
>>>> >> jakarta
>>>> >> >>>>> JM> dependency missing. It seems that some of the dependencies
>>>> won't
>>>> >> >>>>> JM> have the jakarta namespace artifact released in the near
>>>> future.
>>>> >> >>>>> Should we
>>>> >> >>>>> JM> have some milestone/alpha release
>>>> >> >>>>> JM> before all these dependencies are available ? And if we
>>>> want to
>>>> >> do
>>>> >> >>>>> a
>>>> >> >>>>> JM> milestone release, what do you think we should have in
>>>> >> >>>>> JM> this 4.0.0-M1 release ?
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> JM> Thanks,
>>>> >> >>>>> JM> Jim
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma <
>>>> mail2ji...@gmail.com>
>>>> >> >>>>> wrote:
>>>> >> >>>>>
>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>>>> >> >>>>> >>
>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>>>> drr...@gmail.com>
>>>> >> >>>>> wrote:
>>>> >> >>>>> >>
>>>> >> >>>>> >>> Hey guys,
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> The Jakarta branch [1] just went into master, HUGE THANKS
>>>> >> everyone
>>>> >> >>>>> for
>>>> >> >>>>> >>> tremendous effort! Please
>>>> >> >>>>> >>> note, it is still work in progress, the things to be done
>>>> are
>>>> >> >>>>> tracked
>>>> >> >>>>> >>> under [2], feel free to
>>>> >> >>>>> >>> add more items or pick the existing ones. The master
>>>> builds still
>>>> >> >>>>> have
>>>> >> >>>>> >>> some tests failing, but those
>>>> >> >>>>> >>> should be fixed shortly. With that, 3.6.x-fixes becomes the
>>>> >> >>>>> "mirror" of
>>>> >> >>>>> >>> the master but for javax.*
>>>> >> >>>>> >>> packages. Cherrypicking / backporting changes from master
>>>> might
>>>> >> be
>>>> >> >>>>> a bit
>>>> >> >>>>> >>> more complicated (jakarta.* -> javax.*)
>>>> >> >>>>> >>> but manageable.
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> One more thing, the pull requests against master and 3.6.x
>>>> /
>>>> >> 3.5.x
>>>> >> >>>>> are
>>>> >> >>>>> >>> build using JDK-17 now (was JDK-11
>>>> >> >>>>> >>> before), this is due to the fact that master needs JDK-17,
>>>> as
>>>> >> it's
>>>> >> >>>>> Spring
>>>> >> >>>>> >>> 6 / Spring Boot 3 JDK baseline.
>>>> >> >>>>> >>> I have difficulties configuring Jenkins Maven builds +
>>>> Github
>>>> >> Pull
>>>> >> >>>>> >>> Request builder per branch. It may be
>>>> >> >>>>> >>> possible with pipeline, I will experiment with that.
>>>> Please share
>>>> >> >>>>> any
>>>> >> >>>>> >>> concerns, comments or feedback, it
>>>> >> >>>>> >>> is highly appreciated.
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> Thank you!
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> [1] https://github.com/apache/cxf/pull/912
>>>> >> >>>>> >>> [2] https://issues.apache.org/jira/browse/CXF-8371
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> Best Regards,
>>>> >> >>>>> >>> Andriy Redko
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> COh> +1 from me.
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> COh> Colm.
>>>> >> >>>>> >>>
>>>> >> >>>>> >>> COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma <
>>>> >> mail2ji...@gmail.com>
>>>> >> >>>>> wrote:
>>>> >> >>>>> >>> >>
>>>> >> >>>>> >>> >> Hi Andriy,
>>>> >> >>>>> >>> >> A good plan. I agree with all these changes and support
>>>> >> versions.
>>>> >> >>>>> >>> >>
>>>> >> >>>>> >>> >> Thanks,
>>>> >> >>>>> >>> >> Jim
>>>> >> >>>>> >>> >>
>>>> >> >>>>> >>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko <
>>>> >> drr...@gmail.com>
>>>> >> >>>>> >>> wrote:
>>>> >> >>>>> >>> >>
>>>> >> >>>>> >>> >> > Hey folks,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > While the work on 4.x / Jakarta is slowly but steadily
>>>> >> moving
>>>> >> >>>>> >>> forward, it
>>>> >> >>>>> >>> >> > is
>>>> >> >>>>> >>> >> > time to think about next 3.x release line. As we
>>>> discussed
>>>> >> in
>>>> >> >>>>> this
>>>> >> >>>>> >>> thread,
>>>> >> >>>>> >>> >> > it
>>>> >> >>>>> >>> >> > seems we agreed on 3.6.x to be next javax.* based
>>>> release,
>>>> >> with
>>>> >> >>>>> >>> JDK-11 as
>>>> >> >>>>> >>> >> > the
>>>> >> >>>>> >>> >> > baseline. We have new Spring Boot 2.7.0 just released
>>>> [1],
>>>> >> >>>>> along
>>>> >> >>>>> >>> with tons
>>>> >> >>>>> >>> >> > of other
>>>> >> >>>>> >>> >> > related projects. I would like to propose to:
>>>> >> >>>>> >>> >> > - branch off 3.6.x-fixes (from master) and work on
>>>> upgrades
>>>> >> >>>>> (+ some
>>>> >> >>>>> >>> new
>>>> >> >>>>> >>> >> > features)
>>>> >> >>>>> >>> >> > - as per @Jim suggestion, merge (very soon) Jakarta
>>>> branch
>>>> >> >>>>> [2] into
>>>> >> >>>>> >>> master
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > From the support perspective, it means we would need
>>>> to
>>>> >> >>>>> maintain
>>>> >> >>>>> >>> 3.4.x for
>>>> >> >>>>> >>> >> > some
>>>> >> >>>>> >>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at
>>>> some
>>>> >> >>>>> point).
>>>> >> >>>>> >>> What do
>>>> >> >>>>> >>> >> > you
>>>> >> >>>>> >>> >> > think guys? Thank you!
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > [1]
>>>> >> >>>>> >>>
>>>> >> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now
>>>> >> >>>>> >>> >> > [2] https://github.com/apache/cxf/pull/912
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > Best Regards,
>>>> >> >>>>> >>> >> > Andriy Redko
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > JM> Hi Andriy,
>>>> >> >>>>> >>> >> > JM> I took some time to look at the CXF java11
>>>> support and
>>>> >> >>>>> spring
>>>> >> >>>>> >>> >> > decoupling
>>>> >> >>>>> >>> >> > JM> last week.
>>>> >> >>>>> >>> >> > JM> Here are some thoughts and initial work:
>>>> >> >>>>> >>> >> > JM> 1) Use cross compile to support java11 . We can
>>>> simply
>>>> >> >>>>> change
>>>> >> >>>>> >>> >> > JM> <cxf.jdk.version> in pom.xml to 11.
>>>> >> >>>>> >>> >> > JM> This will allow the maven compiler plugin to
>>>> build
>>>> >> cxf
>>>> >> >>>>> with
>>>> >> >>>>> >>> java11.
>>>> >> >>>>> >>> >> > JM> 2) We can look at creating some separate modules
>>>> for
>>>> >> Spring
>>>> >> >>>>> >>> relevant
>>>> >> >>>>> >>> >> > JM> code/configuration in the future. Ideally a small
>>>> >> >>>>> >>> >> > JM> number of modules would be better and it will
>>>> make it
>>>> >> >>>>> easy for
>>>> >> >>>>> >>> users
>>>> >> >>>>> >>> >> > to
>>>> >> >>>>> >>> >> > JM> import spring relevant dependencies.
>>>> >> >>>>> >>> >> > JM> Here is my initial work :
>>>> >> >>>>> >>> >> > https://github.com/jimma/cxf/commits/spring
>>>> >> >>>>> >>> >> > JM> <https://github.com/jimma/cxf/commits/spring>.
>>>> This
>>>> >> only
>>>> >> >>>>> touches
>>>> >> >>>>> >>> >> > several
>>>> >> >>>>> >>> >> > JM> cxf modules, I am not
>>>> >> >>>>> >>> >> > JM> sure if this approach will get other blockers and
>>>> >> issues.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > JM> Thanks,
>>>> >> >>>>> >>> >> > JM> Jim
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <
>>>> >> >>>>> drr...@gmail.com>
>>>> >> >>>>> >>> >> > wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> Hey Jim,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> AFAIR this particular topic has popped up several
>>>> times,
>>>> >> a
>>>> >> >>>>> few
>>>> >> >>>>> >>> issues
>>>> >> >>>>> >>> >> > >> exist [1] and
>>>> >> >>>>> >>> >> > >> @Christian even did the POC several years ago [2]
>>>> in
>>>> >> >>>>> attempt to
>>>> >> >>>>> >>> remove
>>>> >> >>>>> >>> >> > >> some of the
>>>> >> >>>>> >>> >> > >> hard Spring dependencies (I don't know the
>>>> outcomes to be
>>>> >> >>>>> fair
>>>> >> >>>>> >>> but I
>>>> >> >>>>> >>> >> > >> suspect it turned
>>>> >> >>>>> >>> >> > >> out to be much more difficult than anticipated).
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> The suggestion I have in mind is to keep JDK-17
>>>> baseline
>>>> >> >>>>> **for
>>>> >> >>>>> >>> now** and
>>>> >> >>>>> >>> >> > >> continue working
>>>> >> >>>>> >>> >> > >> on addressing the blockers (there too many at this
>>>> >> point).
>>>> >> >>>>> Once
>>>> >> >>>>> >>> we get
>>>> >> >>>>> >>> >> > to
>>>> >> >>>>> >>> >> > >> the state when
>>>> >> >>>>> >>> >> > >> the Jakarta branch is at least buildable /
>>>> deployable, we
>>>> >> >>>>> could
>>>> >> >>>>> >>> reassess
>>>> >> >>>>> >>> >> > >> the Spring
>>>> >> >>>>> >>> >> > >> coupling. I am just afraid doing everything at
>>>> once would
>>>> >> >>>>> >>> introduce
>>>> >> >>>>> >>> >> > >> instability in
>>>> >> >>>>> >>> >> > >> codebase and slow down everyone on either of these
>>>> >> efforts.
>>>> >> >>>>> Not
>>>> >> >>>>> >>> sure if
>>>> >> >>>>> >>> >> > >> you agree but
>>>> >> >>>>> >>> >> > >> in any case I am definitely +1 for reducing the
>>>> scope of
>>>> >> >>>>> >>> dependencies on
>>>> >> >>>>> >>> >> > >> Spring, even
>>>> >> >>>>> >>> >> > >> in 3.4.x / 3.5.x release lines.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> Thank you.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> [1] https://issues.apache.org/jira/browse/CXF-5477
>>>> >> >>>>> >>> >> > >> [2]
>>>> >> https://github.com/apache/cxf/tree/poc-remove-spring-bp
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> Best Regards,
>>>> >> >>>>> >>> >> > >> Andriy Redko
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> JM> I accidentally clicked the send button, please
>>>> >> ignore
>>>> >> >>>>> my
>>>> >> >>>>> >>> previous
>>>> >> >>>>> >>> >> > >> email
>>>> >> >>>>> >>> >> > >> JM> and look at this reply.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> JM> On Sat, Jan 29, 2022 at 7:58 PM Jim Ma <
>>>> >> >>>>> mail2ji...@gmail.com>
>>>> >> >>>>> >>> >> > wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>> >> >>>>> >>> drr...@gmail.com>
>>>> >> >>>>> >>> >> > wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> Hey guys,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> A bunch of good things have happened at the
>>>> end of
>>>> >> this
>>>> >> >>>>> year.
>>>> >> >>>>> >>> The
>>>> >> >>>>> >>> >> > 3.5.0
>>>> >> >>>>> >>> >> > >> >>> out and we are in a good
>>>> >> >>>>> >>> >> > >> >>> shape to kick off Jakarta support: the Spring 6
>>>> >> >>>>> milestones and
>>>> >> >>>>> >>> >> > Spring
>>>> >> >>>>> >>> >> > >> >>> Boot 3 snapshots are already
>>>> >> >>>>> >>> >> > >> >>> available. There are tons of things to fix and
>>>> >> address,
>>>> >> >>>>> I have
>>>> >> >>>>> >>> >> > created
>>>> >> >>>>> >>> >> > >> >>> this draft pull request [1]
>>>> >> >>>>> >>> >> > >> >>> with a first batch of changes and TODOs.
>>>> Everyone
>>>> >> >>>>> should be
>>>> >> >>>>> >>> able to
>>>> >> >>>>> >>> >> > >> push
>>>> >> >>>>> >>> >> > >> >>> changes in there, if not
>>>> >> >>>>> >>> >> > >> >>> - please let me know, I could give perms /
>>>> move the
>>>> >> >>>>> branch to
>>>> >> >>>>> >>> CXF
>>>> >> >>>>> >>> >> > >> Github
>>>> >> >>>>> >>> >> > >> >>> repo. Hope in the next
>>>> >> >>>>> >>> >> > >> >>> couple of months we get closer to fully embrace
>>>> >> Jakarta.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> On the not so good news side, Spring 6 has kept
>>>> >> JDK-17
>>>> >> >>>>> >>> baseline. It
>>>> >> >>>>> >>> >> > >> does
>>>> >> >>>>> >>> >> > >> >>> not play well with our
>>>> >> >>>>> >>> >> > >> >>> original plan to stick to JDK-11 baseline for
>>>> 4.x
>>>> >> but I
>>>> >> >>>>> am
>>>> >> >>>>> >>> not sure
>>>> >> >>>>> >>> >> > we
>>>> >> >>>>> >>> >> > >> >>> have any choice here besides
>>>> >> >>>>> >>> >> > >> >>> bumping the baseline as well.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> JM> From the JakartaEE9 release[1]and JakartaEE10
>>>> >> >>>>> plan[2], it
>>>> >> >>>>> >>> still
>>>> >> >>>>> >>> >> > >> needs to
>>>> >> >>>>> >>> >> > >> JM> support JDK11. Jakarta Restful WebService
>>>> 3.0/3.1
>>>> >> and
>>>> >> >>>>> >>> Jakarta XML
>>>> >> >>>>> >>> >> > Web
>>>> >> >>>>> >>> >> > >> JM> Services 3.0/3.1
>>>> >> >>>>> >>> >> > >> JM> apis are the specifications we need to
>>>> implement in
>>>> >> >>>>> CXF, so
>>>> >> >>>>> >>> we
>>>> >> >>>>> >>> >> > need
>>>> >> >>>>> >>> >> > >> to
>>>> >> >>>>> >>> >> > >> JM> build, run and test implementation with JDK11.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> JM> Just thinking this loud, is it possible that
>>>> we
>>>> >> make
>>>> >> >>>>> Spring
>>>> >> >>>>> >>> >> > plugable
>>>> >> >>>>> >>> >> > >> or
>>>> >> >>>>> >>> >> > >> JM> really optional ? 4.x is the major release
>>>> and it's
>>>> >> the
>>>> >> >>>>> >>> chance
>>>> >> >>>>> >>> >> > >> JM> to refactor CXF code(like we move spring
>>>> related
>>>> >> >>>>> >>> source/test to
>>>> >> >>>>> >>> >> > >> separate
>>>> >> >>>>> >>> >> > >> JM> module) to build/run/test without Spring with
>>>> a maven
>>>> >> >>>>> profile.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> JM> [1]
>>>> >> >>>>> >>> >> > >> JM>
>>>> >> >>>>> >>> >> > >>
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>>
>>>> >> >>>>>
>>>> >>
>>>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
>>>> >> >>>>> >>> >> > >> JM> [2]
>>>> >> >>>>> >>> >> > >> JM>
>>>> >> >>>>> >>> >> > >>
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>>
>>>> >> >>>>>
>>>> >>
>>>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> Happy Holidays guys!
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> [1] https://github.com/apache/cxf/pull/888
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy
>>>> Redko <
>>>> >> >>>>> >>> drr...@gmail.com>
>>>> >> >>>>> >>> >> > >> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> Hey Jim,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> No, we don't have a branch just yet,
>>>> primarily
>>>> >> >>>>> because we
>>>> >> >>>>> >>> depend
>>>> >> >>>>> >>> >> > on
>>>> >> >>>>> >>> >> > >> the
>>>> >> >>>>> >>> >> > >> >>> >> few
>>>> >> >>>>> >>> >> > >> >>> >> snapshots in 3.5.0/master.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> @Colm do you have an idea regarding
>>>> xmlschema
>>>> >> 2.3.0
>>>> >> >>>>> release
>>>> >> >>>>> >>> >> > >> timelines?
>>>> >> >>>>> >>> >> > >> >>> >> @Dan do you have an idea regarding neethi
>>>> 3.2.0
>>>> >> >>>>> release
>>>> >> >>>>> >>> >> > timelines?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> At worst, you could create a new branch for
>>>> this
>>>> >> >>>>> feature,
>>>> >> >>>>> >>> or
>>>> >> >>>>> >>> >> > submit
>>>> >> >>>>> >>> >> > >> a
>>>> >> >>>>> >>> >> > >> >>> >> pull request against master which we should
>>>> be
>>>> >> able
>>>> >> >>>>> to
>>>> >> >>>>> >>> re-target
>>>> >> >>>>> >>> >> > >> later
>>>> >> >>>>> >>> >> > >> >>> >> against the right branch (should be easy).
>>>> What do
>>>> >> >>>>> you
>>>> >> >>>>> >>> think?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> JM> This is a good idea. I'll send a PR
>>>> against the
>>>> >> >>>>> master,
>>>> >> >>>>> >>> and
>>>> >> >>>>> >>> >> > later
>>>> >> >>>>> >>> >> > >> we
>>>> >> >>>>> >>> >> > >> >>> can
>>>> >> >>>>> >>> >> > >> >>> JM> decide the place to merge.
>>>> >> >>>>> >>> >> > >> >>> JM> Thanks, Andriy.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> Best Regards,
>>>> >> >>>>> >>> >> > >> >>> >> Andriy Redko
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> JM> Thanks for more updates , Andriy.
>>>> >> >>>>> >>> >> > >> >>> >> JM> Is there a place/workspace branch, I
>>>> can
>>>> >> send a
>>>> >> >>>>> PR
>>>> >> >>>>> >>> for this
>>>> >> >>>>> >>> >> > >> >>> change?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> JM> On Fri, Sep 3, 2021 at 9:20 PM Andriy
>>>> Redko <
>>>> >> >>>>> >>> >> > drr...@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> Hey Jim,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> Thanks a lot for taking the lead on this
>>>> one.
>>>> >> >>>>> Just want
>>>> >> >>>>> >>> to
>>>> >> >>>>> >>> >> > chime
>>>> >> >>>>> >>> >> > >> in
>>>> >> >>>>> >>> >> > >> >>> on a
>>>> >> >>>>> >>> >> > >> >>> >> >> few points. Indeed, as
>>>> >> >>>>> >>> >> > >> >>> >> >> per previous discussion in this thread,
>>>> it
>>>> >> seems
>>>> >> >>>>> like
>>>> >> >>>>> >>> it make
>>>> >> >>>>> >>> >> > >> sense
>>>> >> >>>>> >>> >> > >> >>> to
>>>> >> >>>>> >>> >> > >> >>> >> >> provide only the subset
>>>> >> >>>>> >>> >> > >> >>> >> >> of shaded modules with Jakarta
>>>> namespace. Also,
>>>> >> >>>>> it was
>>>> >> >>>>> >>> >> > confirmed
>>>> >> >>>>> >>> >> > >> >>> >> yesterday
>>>> >> >>>>> >>> >> > >> >>> >> >> that Spring Framework
>>>> >> >>>>> >>> >> > >> >>> >> >> 6 milestones will be available in
>>>> November this
>>>> >> >>>>> year
>>>> >> >>>>> >>> but the
>>>> >> >>>>> >>> >> > >> first
>>>> >> >>>>> >>> >> > >> >>> >> >> snapshots will be out in late
>>>> >> >>>>> >>> >> > >> >>> >> >> September / early October, looks pretty
>>>> >> >>>>> promising. One
>>>> >> >>>>> >>> >> > >> >>> **unexpected**
>>>> >> >>>>> >>> >> > >> >>> >> part
>>>> >> >>>>> >>> >> > >> >>> >> >> of the announcement
>>>> >> >>>>> >>> >> > >> >>> >> >> is JDK17 baseline for Spring Framework &
>>>> Co,
>>>> >> that
>>>> >> >>>>> could
>>>> >> >>>>> >>> be a
>>>> >> >>>>> >>> >> > >> bummer
>>>> >> >>>>> >>> >> > >> >>> but
>>>> >> >>>>> >>> >> > >> >>> >> I
>>>> >> >>>>> >>> >> > >> >>> >> >> have the feeling that
>>>> >> >>>>> >>> >> > >> >>> >> >> it will be lowered to JDK11. Thank you.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> Best Regards,
>>>> >> >>>>> >>> >> > >> >>> >> >> Andriy Redko
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> Good point, Romain. We need to look
>>>> at what
>>>> >> >>>>> to do
>>>> >> >>>>> >>> to make
>>>> >> >>>>> >>> >> > >> sure
>>>> >> >>>>> >>> >> > >> >>> all
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> artifacts are included and
>>>> transformed if
>>>> >> this
>>>> >> >>>>> >>> becomes a
>>>> >> >>>>> >>> >> > cxf
>>>> >> >>>>> >>> >> > >> >>> module.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> BTW, Spring 6 GA supports jakarta
>>>> ee9 will
>>>> >> >>>>> come in
>>>> >> >>>>> >>> Q4
>>>> >> >>>>> >>> >> > 2022 :
>>>> >> >>>>> >>> >> > >> >>> >> >> JM>
>>>> >> >>>>> >>> >> > >> >>> >> >>
>>>> >> >>>>> >>> >> > >> >>> >>
>>>> >> >>>>> >>> >> > >> >>>
>>>> >> >>>>> >>> >> > >>
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>>
>>>> >> >>>>>
>>>> >>
>>>> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> On Fri, Sep 3, 2021 at 6:20 PM Romain
>>>> >> >>>>> Manni-Bucau <
>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>> >> >>>>> >>> mail2ji...@gmail.com>
>>>> >> >>>>> >>> >> > a
>>>> >> >>>>> >>> >> > >> >>> écrit
>>>> >> >>>>> >>> >> > >> >>> >> :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM
>>>> Romain
>>>> >> >>>>> Manni-Bucau <
>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim
>>>> Ma <
>>>> >> >>>>> >>> >> > mail2ji...@gmail.com>
>>>> >> >>>>> >>> >> > >> a
>>>> >> >>>>> >>> >> > >> >>> >> écrit :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>>>> Romain
>>>> >> >>>>> >>> Manni-Bucau <
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibu...@gmail.com> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45,
>>>> Andriy
>>>> >> Redko
>>>> >> >>>>> <
>>>> >> >>>>> >>> >> > >> drr...@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> a
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> écrit :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Hi Romain,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Sorry for the delayed response.
>>>> I have
>>>> >> >>>>> been
>>>> >> >>>>> >>> thinking
>>>> >> >>>>> >>> >> > >> about
>>>> >> >>>>> >>> >> > >> >>> your
>>>> >> >>>>> >>> >> > >> >>> >> >> (and
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Jim) suggestions
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> and came to surprising
>>>> conclusion: do
>>>> >> we
>>>> >> >>>>> >>> actually
>>>> >> >>>>> >>> >> > need to
>>>> >> >>>>> >>> >> > >> >>> >> >> officially
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> release anything
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> to shade/overwrite javax <->
>>>> jakarta?
>>>> >> >>>>> >>> Generally, we
>>>> >> >>>>> >>> >> > could
>>>> >> >>>>> >>> >> > >> >>> shade
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Spring or/and any other
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> dependency but we would
>>>> certainly not
>>>> >> >>>>> bundle it
>>>> >> >>>>> >>> as
>>>> >> >>>>> >>> >> > part
>>>> >> >>>>> >>> >> > >> of
>>>> >> >>>>> >>> >> > >> >>> CXF
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> distribution (I hope you
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> would agree), so not really
>>>> useful
>>>> >> unless
>>>> >> >>>>> we
>>>> >> >>>>> >>> publish
>>>> >> >>>>> >>> >> > >> them.
>>>> >> >>>>> >>> >> > >> >>> As
>>>> >> >>>>> >>> >> > >> >>> >> such,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> probably the best
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> interim solution is to document
>>>> what it
>>>> >> >>>>> takes
>>>> >> >>>>> >>> to shade
>>>> >> >>>>> >>> >> > >> CXF
>>>> >> >>>>> >>> >> > >> >>> >> (javax
>>>> >> >>>>> >>> >> > >> >>> >> >> <->
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta) and let
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> the end users
>>>> (application/service
>>>> >> >>>>> developers)
>>>> >> >>>>> >>> use
>>>> >> >>>>> >>> >> > that
>>>> >> >>>>> >>> >> > >> when
>>>> >> >>>>> >>> >> > >> >>> >> >> needed?
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> In this case
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> basically CXF, Spring, Geronimo,
>>>> >> Swagger,
>>>> >> >>>>> ...
>>>> >> >>>>> >>> would
>>>> >> >>>>> >>> >> > >> follow
>>>> >> >>>>> >>> >> > >> >>> the
>>>> >> >>>>> >>> >> > >> >>> >> same
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> shading rules. At
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> least, we could start with that
>>>> >> >>>>> (documenting the
>>>> >> >>>>> >>> >> > shading
>>>> >> >>>>> >>> >> > >> >>> >> process)
>>>> >> >>>>> >>> >> > >> >>> >> >> and
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> likely get some
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> early feedback while working on
>>>> >> >>>>> full-fledged
>>>> >> >>>>> >>> support?
>>>> >> >>>>> >>> >> > >> WDYT?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> This is what is done and makes it
>>>> hard
>>>> >> for
>>>> >> >>>>> >>> nothing to
>>>> >> >>>>> >>> >> > >> >>> >> maintain/fix -
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> dont even look at tomee solution
>>>> for
>>>> >> >>>>> shading
>>>> >> >>>>> >>> please ;)
>>>> >> >>>>> >>> >> > -
>>>> >> >>>>> >>> >> > >> >>> IMHO.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Being said it costs nothing to
>>>> cxf to
>>>> >> >>>>> produce
>>>> >> >>>>> >>> jakarta
>>>> >> >>>>> >>> >> > >> jars,
>>>> >> >>>>> >>> >> > >> >>> that
>>>> >> >>>>> >>> >> > >> >>> >> it
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> makes it ee 9 compliant and more
>>>> >> >>>>> consistent for
>>>> >> >>>>> >>> all but
>>>> >> >>>>> >>> >> > >> >>> spring
>>>> >> >>>>> >>> >> > >> >>> >> >> usage (ee
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> integrators, plain tomcat 10 users
>>>> >> >>>>> etc...), I
>>>> >> >>>>> >>> think it
>>>> >> >>>>> >>> >> > is
>>>> >> >>>>> >>> >> > >> >>> worth
>>>> >> >>>>> >>> >> > >> >>> >> >> doing it,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> at minimum.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> At least a jakarta jaxrs (over
>>>> jakarta
>>>> >> >>>>> servlet)
>>>> >> >>>>> >>> bundle
>>>> >> >>>>> >>> >> > >> would
>>>> >> >>>>> >>> >> > >> >>> be a
>>>> >> >>>>> >>> >> > >> >>> >> >> good
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> progress, not sure jaxws and
>>>> other parts
>>>> >> >>>>> would be
>>>> >> >>>>> >>> >> > helpful
>>>> >> >>>>> >>> >> > >> >>> since
>>>> >> >>>>> >>> >> > >> >>> >> >> they tend
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> to be in maintainance mode from
>>>> what I
>>>> >> saw.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> So IMHO the best is a
>>>> shade/relocation
>>>> >> in
>>>> >> >>>>> the
>>>> >> >>>>> >>> parent to
>>>> >> >>>>> >>> >> > >> >>> deliver a
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> jakarta artifact for all module +
>>>> a few
>>>> >> >>>>> jakarta
>>>> >> >>>>> >>> bom.
>>>> >> >>>>> >>> >> > But
>>>> >> >>>>> >>> >> > >> if
>>>> >> >>>>> >>> >> > >> >>> too
>>>> >> >>>>> >>> >> > >> >>> >> >> much -
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> which I can see/hear - a jakarta
>>>> jaxrs
>>>> >> >>>>> bundle
>>>> >> >>>>> >>> would
>>>> >> >>>>> >>> >> > work
>>>> >> >>>>> >>> >> > >> too
>>>> >> >>>>> >>> >> > >> >>> >> short
>>>> >> >>>>> >>> >> > >> >>> >> >> term.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> I agree to start with something to
>>>> >> preview
>>>> >> >>>>> and
>>>> >> >>>>> >>> collect
>>>> >> >>>>> >>> >> > more
>>>> >> >>>>> >>> >> > >> >>> ideas
>>>> >> >>>>> >>> >> > >> >>> >> to
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> support ee9. It's good to have a
>>>> branch
>>>> >> to
>>>> >> >>>>> really
>>>> >> >>>>> >>> start
>>>> >> >>>>> >>> >> > >> >>> something
>>>> >> >>>>> >>> >> > >> >>> >> >> for this
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> topic.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> @Romain, do you have a prototype
>>>> with
>>>> >> >>>>> shading or
>>>> >> >>>>> >>> other
>>>> >> >>>>> >>> >> > >> tools
>>>> >> >>>>> >>> >> > >> >>> for a
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> jakarta jaxrs bundle or just some
>>>> basic
>>>> >> >>>>> idea that
>>>> >> >>>>> >>> we can
>>>> >> >>>>> >>> >> > >> have
>>>> >> >>>>> >>> >> > >> >>> a
>>>> >> >>>>> >>> >> > >> >>> >> look
>>>> >> >>>>> >>> >> > >> >>> >> >> at ?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Not ready for cxf but looking at
>>>> >> >>>>> meecrowave-core
>>>> >> >>>>> >>> pom you
>>>> >> >>>>> >>> >> > >> would
>>>> >> >>>>> >>> >> > >> >>> have
>>>> >> >>>>> >>> >> > >> >>> >> >> some
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> idea.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> I just suspect pom deps need some
>>>> >> refinement
>>>> >> >>>>> like
>>>> >> >>>>> >>> >> > >> with/without
>>>> >> >>>>> >>> >> > >> >>> the
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> client (it is useless with java 11
>>>> now and
>>>> >> >>>>> less
>>>> >> >>>>> >>> and less
>>>> >> >>>>> >>> >> > >> >>> desired
>>>> >> >>>>> >>> >> > >> >>> >> >> AFAIK).
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> @Romain Manni-Bucau <
>>>> >> rmannibu...@gmail.com>
>>>> >> >>>>> >>> Thanks for
>>>> >> >>>>> >>> >> > the
>>>> >> >>>>> >>> >> > >> >>> >> update. I
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> looked at the meecrowave-core pom and
>>>> >> >>>>> understood
>>>> >> >>>>> >>> how it
>>>> >> >>>>> >>> >> > >> >>> transforms
>>>> >> >>>>> >>> >> > >> >>> >> >> package
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> names with the shade plugin. Both
>>>> shade
>>>> >> >>>>> plugin or
>>>> >> >>>>> >>> eclipse
>>>> >> >>>>> >>> >> > >> >>> >> transformer
>>>> >> >>>>> >>> >> > >> >>> >> >> tool
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> works for this purpose .
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> I created one prototype project
>>>> which pulls
>>>> >> >>>>> in cxf
>>>> >> >>>>> >>> >> > >> dependencies,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> transforms to jakarta namespace and
>>>> >> installs
>>>> >> >>>>> to
>>>> >> >>>>> >>> local
>>>> >> >>>>> >>> >> > maven
>>>> >> >>>>> >>> >> > >> >>> >> >> repository :
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>
>>>> >> https://github.com/jimma/cxf-ee9-transformer
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> This doesn't need more effort and no
>>>> need
>>>> >> the
>>>> >> >>>>> >>> >> > code/dependency
>>>> >> >>>>> >>> >> > >> >>> change
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> which breaks/mixes with javax support
>>>> >> >>>>> codebase. It
>>>> >> >>>>> >>> can be
>>>> >> >>>>> >>> >> > >> simply
>>>> >> >>>>> >>> >> > >> >>> >> added
>>>> >> >>>>> >>> >> > >> >>> >> >> with
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> another maven module in cxf repo to
>>>> produce
>>>> >> >>>>> >>> transformed
>>>> >> >>>>> >>> >> > >> jakata
>>>> >> >>>>> >>> >> > >> >>> cxf
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> artifacts or binary distribution.
>>>> Your
>>>> >> >>>>> thoughts ?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >> If not all artifacts are proposed with
>>>> >> jakarta
>>>> >> >>>>> >>> support it
>>>> >> >>>>> >>> >> > is
>>>> >> >>>>> >>> >> > >> an
>>>> >> >>>>> >>> >> > >> >>> >> option
>>>> >> >>>>> >>> >> > >> >>> >> >> >> otherwise it would need a build
>>>> module to
>>>> >> >>>>> >>> synchronize this
>>>> >> >>>>> >>> >> > >> >>> >> submodule(s)
>>>> >> >>>>> >>> >> > >> >>> >> >> to
>>>> >> >>>>> >>> >> > >> >>> >> >> >> ensure none are forgotten - this is
>>>> where I
>>>> >> >>>>> prefer
>>>> >> >>>>> >>> the
>>>> >> >>>>> >>> >> > >> classifier
>>>> >> >>>>> >>> >> > >> >>> >> >> approach
>>>> >> >>>>> >>> >> > >> >>> >> >> >> even if it has this exclusion
>>>> pitfalls - but
>>>> >> >>>>> cxf has
>>>> >> >>>>> >>> it
>>>> >> >>>>> >>> >> > anyway
>>>> >> >>>>> >>> >> > >> >>> due to
>>>> >> >>>>> >>> >> > >> >>> >> >> its
>>>> >> >>>>> >>> >> > >> >>> >> >> >> transitive dependencies so not worse
>>>> IMHO
>>>> >> ;).
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Thanks,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Jim
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Thank you.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Best Regards,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Andriy Redko
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> I'm not sure I see why you
>>>> need
>>>> >> >>>>> spring to
>>>> >> >>>>> >>> start
>>>> >> >>>>> >>> >> > this
>>>> >> >>>>> >>> >> > >> >>> work.
>>>> >> >>>>> >>> >> > >> >>> >> The
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> expected is
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> there already so spring
>>>> module can
>>>> >> >>>>> still
>>>> >> >>>>> >>> rely on
>>>> >> >>>>> >>> >> > >> >>> javax, be
>>>> >> >>>>> >>> >> > >> >>> >> >> made
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> friendly using shade plugin
>>>> or
>>>> >> alike
>>>> >> >>>>> and
>>>> >> >>>>> >>> that's
>>>> >> >>>>> >>> >> > it
>>>> >> >>>>> >>> >> > >> >>> until a
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> spring native
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> integration is there.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Worse case cxf-spring will
>>>> not be
>>>> >> >>>>> usable
>>>> >> >>>>> >>> with
>>>> >> >>>>> >>> >> > >> jakarta -
>>>> >> >>>>> >>> >> > >> >>> >> which
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> still enabled
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> all other usages, best case
>>>> if
>>>> >> spring
>>>> >> >>>>> >>> makes the
>>>> >> >>>>> >>> >> > >> >>> transition
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> smooth is that
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> it will work smoothly
>>>> without more
>>>> >> >>>>> >>> investment
>>>> >> >>>>> >>> >> > than
>>>> >> >>>>> >>> >> > >> for
>>>> >> >>>>> >>> >> > >> >>> the
>>>> >> >>>>> >>> >> > >> >>> >> >> rest
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> of the
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> build.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> The pro of that options is
>>>> that it
>>>> >> >>>>> will
>>>> >> >>>>> >>> reduce
>>>> >> >>>>> >>> >> > the
>>>> >> >>>>> >>> >> > >> >>> number
>>>> >> >>>>> >>> >> > >> >>> >> of
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> unofficial cxf
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> relocations sooner IMHO.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Romain Manni-Bucau
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> @rmannibucau <
>>>> >> >>>>> >>> https://twitter.com/rmannibucau> |
>>>> >> >>>>> >>> >> > >> Blog
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> <
>>>> >> https://rmannibucau.metawerx.net/>
>>>> >> >>>>> | Old
>>>> >> >>>>> >>> Blog
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> <
>>>> http://rmannibucau.wordpress.com>
>>>> >> |
>>>> >> >>>>> >>> Github <
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> https://github.com/rmannibucau>
>>>> |
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> LinkedIn <
>>>> >> >>>>> >>> >> > https://www.linkedin.com/in/rmannibucau>
>>>> >> >>>>> >>> >> > >> |
>>>> >> >>>>> >>> >> > >> >>> Book
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> <
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>>
>>>> >> >>>>> >>> >> > >> >>> >> >>
>>>> >> >>>>> >>> >> > >> >>> >>
>>>> >> >>>>> >>> >> > >> >>>
>>>> >> >>>>> >>> >> > >>
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>>
>>>> >> >>>>>
>>>> >>
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Le lun. 16 août 2021 à
>>>> 23:40,
>>>> >> Andriy
>>>> >> >>>>> Redko
>>>> >> >>>>> >>> <
>>>> >> >>>>> >>> >> > >> >>> >> drr...@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> >> >> a
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> écrit :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Hi Jim,
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> I will try to answer your
>>>> questions,
>>>> >> >>>>> other
>>>> >> >>>>> >>> guys
>>>> >> >>>>> >>> >> > will
>>>> >> >>>>> >>> >> > >> >>> >> definitely
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> share more
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> thoughts, please see mine
>>>> inlined.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> What's the task for JDK-17
>>>> LTS
>>>> >> >>>>> >>> preparation ?
>>>> >> >>>>> >>> >> > Do we
>>>> >> >>>>> >>> >> > >> >>> need
>>>> >> >>>>> >>> >> > >> >>> >> to
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> build 3.5.0 with JDK-17 ?
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Build + All tests are green.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Apache Karaf 4.3.3 will
>>>> support
>>>> >> JDK17
>>>> >> >>>>> so our
>>>> >> >>>>> >>> OSGi
>>>> >> >>>>> >>> >> > test
>>>> >> >>>>> >>> >> > >> >>> suites
>>>> >> >>>>> >>> >> > >> >>> >> >> will
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> pass.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Besides that, there is still
>>>> some
>>>> >> work
>>>> >> >>>>> to do
>>>> >> >>>>> >>> [1]
>>>> >> >>>>> >>> >> > but
>>>> >> >>>>> >>> >> > >> at
>>>> >> >>>>> >>> >> > >> >>> >> least we
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> workarounds.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> For Jakarta ee9 support
>>>> branch
>>>> >> 4.x
>>>> >> >>>>> with
>>>> >> >>>>> >>> source
>>>> >> >>>>> >>> >> > code
>>>> >> >>>>> >>> >> > >> >>> >> change to
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> jakarta namespace , we have
>>>> to wait
>>>> >> for
>>>> >> >>>>> >>> spring and
>>>> >> >>>>> >>> >> > >> other
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> third party dependencies
>>>> jakarta
>>>> >> ee9
>>>> >> >>>>> >>> ready.
>>>> >> >>>>> >>> >> > Now we
>>>> >> >>>>> >>> >> > >> >>> don't
>>>> >> >>>>> >>> >> > >> >>> >> >> know
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> when
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> these dependencies are all
>>>> ready and
>>>> >> >>>>> we can
>>>> >> >>>>> >>> start
>>>> >> >>>>> >>> >> > this
>>>> >> >>>>> >>> >> > >> >>> work.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> This is correct, the earliest
>>>> we
>>>> >> could
>>>> >> >>>>> expect
>>>> >> >>>>> >>> >> > >> something
>>>> >> >>>>> >>> >> > >> >>> is
>>>> >> >>>>> >>> >> > >> >>> >> >> Q4/2021
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> (fe
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Spring).
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> Given there is no features
>>>> added
>>>> >> in
>>>> >> >>>>> >>> Jakarta ee
>>>> >> >>>>> >>> >> > 9.1
>>>> >> >>>>> >>> >> > >> >>> besides
>>>> >> >>>>> >>> >> > >> >>> >> >> the
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> namespace change, we can
>>>> provide the
>>>> >> >>>>> jakarta
>>>> >> >>>>> >>> >> > calssfier
>>>> >> >>>>> >>> >> > >> >>> maven
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> artifacts
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> and binary release in
>>>> 3.6.x or
>>>> >> 4.x
>>>> >> >>>>> with
>>>> >> >>>>> >>> >> > >> >>> transformation or
>>>> >> >>>>> >>> >> > >> >>> >> >> other
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> better
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> approach will be enough.We
>>>> provide
>>>> >> >>>>> jakarta
>>>> >> >>>>> >>> ee9
>>>> >> >>>>> >>> >> > support
>>>> >> >>>>> >>> >> > >> >>> early,
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> then we can get more
>>>> feedback on
>>>> >> >>>>> this
>>>> >> >>>>> >>> topic.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> It is definitely the option
>>>> we have
>>>> >> >>>>> among
>>>> >> >>>>> >>> others to
>>>> >> >>>>> >>> >> > >> >>> discuss.
>>>> >> >>>>> >>> >> > >> >>> >> I
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have no
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> doubts that everyone has
>>>> rough idea
>>>> >> of
>>>> >> >>>>> the
>>>> >> >>>>> >>> pros and
>>>> >> >>>>> >>> >> > >> cons
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> each option has, as the team
>>>> we are
>>>> >> >>>>> trying
>>>> >> >>>>> >>> to pick
>>>> >> >>>>> >>> >> > the
>>>> >> >>>>> >>> >> > >> >>> best
>>>> >> >>>>> >>> >> > >> >>> >> path
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> forward.
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Jakarta EE 10 is coming in
>>>> Q1/2022
>>>> >> >>>>> [2], we
>>>> >> >>>>> >>> should
>>>> >> >>>>> >>> >> > >> keep it
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> in mind as well.
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Thank you!
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> [1]
>>>> >> >>>>> >>> <https://issues.apache.org/jira/browse/CXF-8407>
>>>
>>>
