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