Hi Jim,
It sounds easier, requiring less efforts, I agree.
Colm, Freeman, are you on board with this approach guys?
Thanks!
Best Regards,
Andriy Redko
JM> Hi Andriy,
JM> From what I looked at last time, it seems it's difficult to decouple these
JM> osgi/karaf integration code from cxf core
JM> and create a new project to put it into a separate repository. IMO, we can
JM> create a branch before we
JM> remove these integration codes, and later we can look at this branch to
JM> restore the osgi/integration code when
JM> osgi jakarta support is available. Your thoughts?
JM> Thanks,
JM> Jim
JM> On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko <drr...@gmail.com> wrote:
>> Hey guys,
>>
>> Thanks a lot for bringing the clarity on possible timelines. @Jim, how do
>> you want
>> to proceed with that? Do you think it is good idea to move off Apache
>> Karaf integration
>> into separate repository altogether (we discussed that a few times as
>> well)? Should we
>> preserve the OSGi-related hooks but replace them with "dummy"
>> implementation (like HTTP
>> transport for example)? @Colm, @Freeman what do you think? (assuming the
>> goal is to put
>> this chunk of codebase aside and bring it back when time comes).
>>
>> Thanks!
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>> > 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
>>
>>
