Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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. 

Happy Holidays guys!

[1] https://github.com/apache/cxf/pull/888

JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy Redko <dr...@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 <dr...@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 <
>> >> rmannibucau@gmail.com>
>> >> JM> wrote:




>> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a écrit
>> :



>> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >> rmannibucau@gmail.com>
>> >> >>> wrote:



>> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com> a
>> écrit :



>> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> >> >>>>> rmannibucau@gmail.com> wrote:



>> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <dr...@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 <rm...@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 <
>> drreta@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 <
>> >> drreta@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 <
>> >> >>>>>>> drreta@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.20201226124316@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

Re: [DISCUSS] CXF 3.5.x and beyond

[Freeman Fang <fr...@gmail.com>]

Thanks Jim, I will take a close look!

Freeman

On Wed, Sep 21, 2022 at 4:02 AM Jim Ma <ma...@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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <dr...@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 <
>> mail2jimma@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >> >>>>> >>
>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>> drreta@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 <
>> >> mail2jimma@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 <
>> >> drreta@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 <
>> >> >>>>> drreta@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 <
>> >> >>>>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> >> > drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >> >>>>> >>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > a
>> >> >>>>> >>> >> > >> >>> écrit
>> >> >>>>> >>> >> > >> >>> >> :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >> >>>>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>> >> >>>>> >>> >> > >> a
>> >> >>>>> >>> >> > >> >>> >> écrit :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>> Romain
>> >> >>>>> >>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>> >> Redko
>> >> >>>>> <
>> >> >>>>> >>> >> > >> drreta@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 <
>> >> rmannibucau@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
>> >> >>>>> >>> <
>> >> >>>>> >>> >> > >> >>> >> drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@gmail.com%3E
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [3]
>> >> >>>>> >>> https://github.com/apache/cxf/pull/737
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [4]
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >>
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >>
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>>
>> >> >>>>> >>> >> > >> >>> >> >>
>> >> >>>>> >>> >> > >> >>> >>
>> >> >>>>> >>> >> > >> >>>
>> >> >>>>> >>> >> > >>
>> >> >>>>> >>> >> >
>> >> >>>>> >>>
>> >> >>>>>
>> >>
>> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> Best Regards,
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>     Andriy Redko
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>>
>> >> >>>>> >>>
>> >> >>>>>
>> >> >>>>>
>> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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.fang@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 <ma...@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 <dr...@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 <
>> mail2jimma@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >> >>>>> >>
>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>> drreta@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 <
>> >> mail2jimma@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 <
>> >> drreta@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 <
>> >> >>>>> drreta@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 <
>> >> >>>>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> >> > drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >> >>>>> >>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > a
>> >> >>>>> >>> >> > >> >>> écrit
>> >> >>>>> >>> >> > >> >>> >> :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >> >>>>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>> >> >>>>> >>> >> > >> a
>> >> >>>>> >>> >> > >> >>> >> écrit :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>> Romain
>> >> >>>>> >>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>> >> Redko
>> >> >>>>> <
>> >> >>>>> >>> >> > >> drreta@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 <
>> >> rmannibucau@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
>> >> >>>>> >>> <
>> >> >>>>> >>> >> > >> >>> >> drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>>
>> >> >>>>> >>>
>> >> >>>>>
>> >> >>>>>
>> >>
>> >>
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[David Blevins <da...@gmail.com>]

Hey Andriy,

Sounds like a workable plan.  If 4.0.0 is still ongoing once TomEE 9 is released, I'd help there before moving onto any potential 4.1 work.  I'd expect TomEE 10 work to go far into next year, so there's no immediate time pressure -- just trying to get a feel for how it might all come together.

Yeah, the dependencies are the hardest part.  We still bytecode transform about 5 or 6 of them in TomEE 9.  That would definitely be one of the ways I could help once I'm freed up after TomEE 9.


-David


> On Oct 9, 2022, at 11:10 AM, Andriy Redko <dr...@gmail.com> wrote:
> 
> Thanks David. I think the most efficient way for CXF team is to focus on 4.0.0. We have a few 
> blockers along the way which we are working on. To put it in perspective, there are modules which 
> are excluded from the builds at the moment, no equivalent replacement of the dependencies in Jakarta
> space, but eventually those should be there. In any case, I think the way to approach the contrubutions
> to 4.1 could be to create the pull request against main (for now), once 4.0.0 is branched off, it could
> be merged. It may not the most convenient for you, but would help us to focus on 4.0.0 only. What do you
> think?
> 
> Thank you.
> 
> Best Regards,
>    Andriy Redko 
> 
>>> On Oct 8, 2022, at 8:21 PM, Andriy Redko <dr...@gmail.com> wrote:
>>> 
>>> I was thinking about that as well, since Jakarta EE 10 is already out [1]. If I am not mistaken,
>>> we haven't discussed the future Jakarta plans yet, trying to address major 4.0.0 migration issues. 
>>> Personally I was thinking that having 4.1.x release dedicated to Jakarta EE 10 is probably way to 
>>> go (and consequently following this branching strategy for the future Jakarta EE releases like 
>>> 4.2.x, 4.3.x, ...). I am curious what others think about that.
> 
> DB> That sounds like a good plan to me.
> 
> DB> I know on the TomEE side the community seems to be anxious to get 9 out the door so work on 10 can start.  Likely that means 9 will immediately get branched and go into maintenance mode, which is a bit different to what we'd normally do.  Usually the next version doesn't really start for quite a few months.
> 
> DB> Do we think we might be willing to accept contributions on a potential 4.1 pretty soon after 4.0 goes final or would there be some desire to let 4.0.0 mature for a few months before starting a potential 4.1?
> 
> 
> DB> -David
> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Thanks David. I think the most efficient way for CXF team is to focus on 4.0.0. We have a few 
blockers along the way which we are working on. To put it in perspective, there are modules which 
are excluded from the builds at the moment, no equivalent replacement of the dependencies in Jakarta
space, but eventually those should be there. In any case, I think the way to approach the contrubutions
to 4.1 could be to create the pull request against main (for now), once 4.0.0 is branched off, it could
be merged. It may not the most convenient for you, but would help us to focus on 4.0.0 only. What do you
think?
 
Thank you.

Best Regards,
    Andriy Redko 

>> On Oct 8, 2022, at 8:21 PM, Andriy Redko <dr...@gmail.com> wrote:
>> 
>> I was thinking about that as well, since Jakarta EE 10 is already out [1]. If I am not mistaken,
>> we haven't discussed the future Jakarta plans yet, trying to address major 4.0.0 migration issues. 
>> Personally I was thinking that having 4.1.x release dedicated to Jakarta EE 10 is probably way to 
>> go (and consequently following this branching strategy for the future Jakarta EE releases like 
>> 4.2.x, 4.3.x, ...). I am curious what others think about that.

DB> That sounds like a good plan to me.

DB> I know on the TomEE side the community seems to be anxious to get 9 out the door so work on 10 can start.  Likely that means 9 will immediately get branched and go into maintenance mode, which is a bit different to what we'd normally do.  Usually the next version doesn't really start for quite a few months.

DB> Do we think we might be willing to accept contributions on a potential 4.1 pretty soon after 4.0 goes final or would there be some desire to let 4.0.0 mature for a few months before starting a potential 4.1?


DB> -David

Re: [DISCUSS] CXF 3.5.x and beyond

[David Blevins <da...@gmail.com>]

> On Oct 8, 2022, at 8:21 PM, Andriy Redko <dr...@gmail.com> wrote:
> 
> I was thinking about that as well, since Jakarta EE 10 is already out [1]. If I am not mistaken,
> we haven't discussed the future Jakarta plans yet, trying to address major 4.0.0 migration issues. 
> Personally I was thinking that having 4.1.x release dedicated to Jakarta EE 10 is probably way to 
> go (and consequently following this branching strategy for the future Jakarta EE releases like 
> 4.2.x, 4.3.x, ...). I am curious what others think about that.

That sounds like a good plan to me.

I know on the TomEE side the community seems to be anxious to get 9 out the door so work on 10 can start.  Likely that means 9 will immediately get branched and go into maintenance mode, which is a bit different to what we'd normally do.  Usually the next version doesn't really start for quite a few months.

Do we think we might be willing to accept contributions on a potential 4.1 pretty soon after 4.0 goes final or would there be some desire to let 4.0.0 mature for a few months before starting a potential 4.1?


-David

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Hey David,

I was thinking about that as well, since Jakarta EE 10 is already out [1]. If I am not mistaken,
we haven't discussed the future Jakarta plans yet, trying to address major 4.0.0 migration issues. 
Personally I was thinking that having 4.1.x release dedicated to Jakarta EE 10 is probably way to 
go (and consequently following this branching strategy for the future Jakarta EE releases like 
4.2.x, 4.3.x, ...). I am curious what others think about that.

Last but not least, your understanding of the current state of 4.0.0 is correct.
Thank you.

[1] https://jakarta.ee/release/10/

Best Regards,
    Andriy Redko

DB> Jumping into a random spot in this thread.

DB> My understanding of the current state of 4.0.0 is:

DB>  - Targets Java 17 due to Spring deps
DB>  - Targets Jakarta EE 9 / Jakarta Rest 3.0

DB> The trick for us on the TomEE side is that Jakarta EE 9.1 requires support for Java 11.  We're still using 3.5.x with bytecode transformation, which is fine for TomEE 9.  It's nearly done.

DB> Our first opportunity to set Java 17 as the base is Jakarta EE 10.  The trick for us there is we'd need Jakarta Rest 3.1.

DB> We're hoping to get TomEE 9 out the door this year and once that is done we'd be turning our attention to TomEE 10, which is primarily going to involve contributing to the projects we need.  My question, is where would contributions to Jakarta Rest 3.1 be welcome?

DB> Is there some willingness to go straight to Jakarta Rest 3.1 in CXF 4.0.0 if help showed up or would we want that in a separate branch? (4.1.x or 5.x?)

DB> Thoughts?


DB> -David


>> On Sep 29, 2022, at 7:03 PM, Andriy Redko <dr...@gmail.com> wrote:
>> 
>> Hey Colm,
>> 
>> All skipped projects are listed here [1], the test cases (for now) don't have JIRAs
>> but will be fixed at some point (hopefully - very soon), I am not sure we need separate
>> tickets for that since we don't silence/ignore them. Thanks! 
>> 
>> [1] https://issues.apache.org/jira/browse/CXF-8724
>> 
>> Best Regards,
>>    Andriy Redko
>> 
>> COh> Hi,
>> 
>> COh> No objection from me either. Apart from OSGi, could we make sure that
>> COh> all the gaps are recorded in JIRA?
>> 
>> COh>  * Test failures in cxf-rt-mp-client -
>> COh> https://issues.apache.org/jira/browse/CXF-8758
>> COh>  * Test failures in
>> COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
>> COh> related) - https://issues.apache.org/jira/browse/CXF-8717
>> COh>  * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
>> COh> failing in the jms transport systests - JIRA?
>> COh>  * ./systests/container-integration/grizzly skipped -
>> COh> https://issues.apache.org/jira/browse/CXF-8716
>> COh>  * jaxrs systests skipped - JIRA?
>> COh>  * systests/wsdl_maven/codegen skipped - JIRA?
>> COh>  * maven-plugins/wadl2java-plugin - JIRA?
>> COh>  * maven-plugins/java2swagger-plugin - JIRA?
>> 
>> COh> Colm.
>> 
>> COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
>>>> 
>>>> Hi Jim,
>>>> 
>>>> No objections from my side, thank you.
>>>> 
>>>> Best Regards,
>>>>    Andriy Redko
>>>> 
>>>> On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
>>>>>>> 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
>>>>>>> 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 <dr...@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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thanks Andriy too for driving this and moving forward !
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>>>>>>>>>> mail2jimma@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 <
>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JM> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> écrit
>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>>>>>>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>>>>>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>>>>>>>>>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>>>>>>>>>> Redko
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>> rmannibucau@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
>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> drreta@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]
>>>>>>>>>>>>>>>>>> 
>> 

Re: [DISCUSS] CXF 3.5.x and beyond

[David Blevins <da...@gmail.com>]

Jumping into a random spot in this thread.

My understanding of the current state of 4.0.0 is:

 - Targets Java 17 due to Spring deps
 - Targets Jakarta EE 9 / Jakarta Rest 3.0

The trick for us on the TomEE side is that Jakarta EE 9.1 requires support for Java 11.  We're still using 3.5.x with bytecode transformation, which is fine for TomEE 9.  It's nearly done.

Our first opportunity to set Java 17 as the base is Jakarta EE 10.  The trick for us there is we'd need Jakarta Rest 3.1.

We're hoping to get TomEE 9 out the door this year and once that is done we'd be turning our attention to TomEE 10, which is primarily going to involve contributing to the projects we need.  My question, is where would contributions to Jakarta Rest 3.1 be welcome?

Is there some willingness to go straight to Jakarta Rest 3.1 in CXF 4.0.0 if help showed up or would we want that in a separate branch? (4.1.x or 5.x?)

Thoughts?


-David


> On Sep 29, 2022, at 7:03 PM, Andriy Redko <dr...@gmail.com> wrote:
> 
> Hey Colm,
> 
> All skipped projects are listed here [1], the test cases (for now) don't have JIRAs
> but will be fixed at some point (hopefully - very soon), I am not sure we need separate
> tickets for that since we don't silence/ignore them. Thanks! 
> 
> [1] https://issues.apache.org/jira/browse/CXF-8724
> 
> Best Regards,
>    Andriy Redko
> 
> COh> Hi,
> 
> COh> No objection from me either. Apart from OSGi, could we make sure that
> COh> all the gaps are recorded in JIRA?
> 
> COh>  * Test failures in cxf-rt-mp-client -
> COh> https://issues.apache.org/jira/browse/CXF-8758
> COh>  * Test failures in
> COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
> COh> related) - https://issues.apache.org/jira/browse/CXF-8717
> COh>  * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
> COh> failing in the jms transport systests - JIRA?
> COh>  * ./systests/container-integration/grizzly skipped -
> COh> https://issues.apache.org/jira/browse/CXF-8716
> COh>  * jaxrs systests skipped - JIRA?
> COh>  * systests/wsdl_maven/codegen skipped - JIRA?
> COh>  * maven-plugins/wadl2java-plugin - JIRA?
> COh>  * maven-plugins/java2swagger-plugin - JIRA?
> 
> COh> Colm.
> 
> COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> No objections from my side, thank you.
>>> 
>>> Best Regards,
>>>    Andriy Redko
>>> 
>>> On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
>>>>>> 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
>>>>>> 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 <dr...@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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks Andriy too for driving this and moving forward !
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>>>>>>>>> mail2jimma@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 <
>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JM> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>> écrit
>>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>>>>>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>>>>>>>>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>>>>>>>>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>>>>>>>>> Redko
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> drreta@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 <
>>>>>>>>> rmannibucau@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
>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>> drreta@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]
>>>>>>>>>>>>>>>>> 
> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Hey Colm,

All skipped projects are listed here [1], the test cases (for now) don't have JIRAs
but will be fixed at some point (hopefully - very soon), I am not sure we need separate
tickets for that since we don't silence/ignore them. Thanks! 

[1] https://issues.apache.org/jira/browse/CXF-8724

Best Regards,
    Andriy Redko

COh> Hi,

COh> No objection from me either. Apart from OSGi, could we make sure that
COh> all the gaps are recorded in JIRA?

COh>  * Test failures in cxf-rt-mp-client -
COh> https://issues.apache.org/jira/browse/CXF-8758
COh>  * Test failures in
COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
COh> related) - https://issues.apache.org/jira/browse/CXF-8717
COh>  * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
COh> failing in the jms transport systests - JIRA?
COh>  * ./systests/container-integration/grizzly skipped -
COh> https://issues.apache.org/jira/browse/CXF-8716
COh>  * jaxrs systests skipped - JIRA?
COh>  * systests/wsdl_maven/codegen skipped - JIRA?
COh>  * maven-plugins/wadl2java-plugin - JIRA?
COh>  * maven-plugins/java2swagger-plugin - JIRA?

COh> Colm.

COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
>>
>> Hi Jim,
>>
>> No objections from my side, thank you.
>>
>> Best Regards,
>>     Andriy Redko
>>
>> On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
>>>>> 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
>>>>> 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 <dr...@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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>>> >> >>>>> wrote:
>>>>>> >> >>>>>
>>>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>>>>>> >> >>>>> >>
>>>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>>>>>> >> mail2jimma@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 <
>>>>>> >> drreta@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 <
>>>>>> >> >>>>> drreta@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 <
>>>>>> >> >>>>> mail2jimma@gmail.com>
>>>>>> >> >>>>> >>> >> > wrote:
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>>> >> >>>>> >>> drreta@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 <
>>>>>> >> >>>>> >>> drreta@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 <
>>>>>> >> >>>>> >>> >> > drreta@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 <
>>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>>> >> >>>>> >>> mail2jimma@gmail.com>
>>>>>> >> >>>>> >>> >> > a
>>>>>> >> >>>>> >>> >> > >> >>> écrit
>>>>>> >> >>>>> >>> >> > >> >>> >> :
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>>> >> >>>>> Manni-Bucau <
>>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>>>>>> >> >>>>> >>> >> > >> a
>>>>>> >> >>>>> >>> >> > >> >>> >> écrit :
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>>> >> >>>>> >>> Manni-Bucau <
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> >
>>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>>>>>> >> Redko
>>>>>> >> >>>>> <
>>>>>> >> >>>>> >>> >> > >> drreta@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 <
>>>>>> >> rmannibucau@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
>>>>>> >> >>>>> >>> <
>>>>>> >> >>>>> >>> >> > >> >>> >> drreta@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]
>>>>>> >> >>>>> >>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Hey Jim,

Yes, the maven-plugins/wadl2java-plugin is blocked by [1], no Jakarta release.
Thanks!

[1] https://github.com/highsource/jaxb2-basics

Best Regards,
    Andriy Redko

JM> I already created a branch for the pre-removal and merged this osgi removal
JM> change to the main branch .
JM> For these test failures and skipped modules, I'll have a look and fill a
JM> JIRA for them after I resolve the
JM> grizzly jakarta upgrade : https://issues.apache.org/jira/browse/CXF-8716.

JM> @Andriy Redko <dr...@gmail.com> Do you remember why we skipped the
JM> maven-plugins/wadl2java-plugin and systests/wsdl_maven/codegen ?
JM> I remembered we analyzed this before , but I can't find the discussion log.



JM> On Wed, Sep 28, 2022 at 4:30 PM Colm O hEigeartaigh <co...@apache.org>
JM> wrote:

>> Hi,
>>
>> No objection from me either. Apart from OSGi, could we make sure that
>> all the gaps are recorded in JIRA?
>>
>>  * Test failures in cxf-rt-mp-client -
>> https://issues.apache.org/jira/browse/CXF-8758
>>  * Test failures in
>> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
>> related) - https://issues.apache.org/jira/browse/CXF-8717
>>  * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
>> failing in the jms transport systests - JIRA?
>>  * ./systests/container-integration/grizzly skipped -
>> https://issues.apache.org/jira/browse/CXF-8716
>>  * jaxrs systests skipped - JIRA?
>>  * systests/wsdl_maven/codegen skipped - JIRA?
>>  * maven-plugins/wadl2java-plugin - JIRA?
>>  * maven-plugins/java2swagger-plugin - JIRA?
>>
>> Colm.
>>
>> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
>> >
>> > Hi Jim,
>> >
>> > No objections from my side, thank you.
>> >
>> > Best Regards,
>> >     Andriy Redko
>> >
>> > On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
>> >>>> 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
>> >>>> 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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <
>> drreta@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 <
>> mail2jimma@gmail.com>
>> >>>>> >> >>>>> wrote:
>> >>>>> >> >>>>>
>> >>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >>>>> >> >>>>> >>
>> >>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>> drreta@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 <
>> >>>>> >> mail2jimma@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 <
>> >>>>> >> drreta@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 <
>> >>>>> >> >>>>> drreta@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 <
>> >>>>> >> >>>>> mail2jimma@gmail.com>
>> >>>>> >> >>>>> >>> >> > wrote:
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy
>> Redko <
>> >>>>> >> >>>>> >>> drreta@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 <
>> >>>>> >> >>>>> >>> drreta@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 <
>> >>>>> >> >>>>> >>> >> > drreta@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 <
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim
>> Ma <
>> >>>>> >> >>>>> >>> mail2jimma@gmail.com>
>> >>>>> >> >>>>> >>> >> > a
>> >>>>> >> >>>>> >>> >> > >> >>> écrit
>> >>>>> >> >>>>> >>> >> > >> >>> >> :
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM
>> Romain
>> >>>>> >> >>>>> Manni-Bucau <
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39,
>> Jim Ma <
>> >>>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>> >>>>> >> >>>>> >>> >> > >> a
>> >>>>> >> >>>>> >>> >> > >> >>> >> écrit :
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>> Romain
>> >>>>> >> >>>>> >>> Manni-Bucau <
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> >
>> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45,
>> Andriy
>> >>>>> >> Redko
>> >>>>> >> >>>>> <
>> >>>>> >> >>>>> >>> >> > >> drreta@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 <
>> >>>>> >> rmannibucau@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
>> >>>>> >> >>>>> >>> <
>> >>>>> >> >>>>> >>> >> > >> >>> >> drreta@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]
>> >>>>> >> >>>>> >>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

I already created a branch for the pre-removal and merged this osgi removal
change to the main branch .
For these test failures and skipped modules, I'll have a look and fill a
JIRA for them after I resolve the
grizzly jakarta upgrade : https://issues.apache.org/jira/browse/CXF-8716.

@Andriy Redko <dr...@gmail.com> Do you remember why we skipped the
maven-plugins/wadl2java-plugin and systests/wsdl_maven/codegen ?
I remembered we analyzed this before , but I can't find the discussion log.



On Wed, Sep 28, 2022 at 4:30 PM Colm O hEigeartaigh <co...@apache.org>
wrote:

> Hi,
>
> No objection from me either. Apart from OSGi, could we make sure that
> all the gaps are recorded in JIRA?
>
>  * Test failures in cxf-rt-mp-client -
> https://issues.apache.org/jira/browse/CXF-8758
>  * Test failures in
> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
> related) - https://issues.apache.org/jira/browse/CXF-8717
>  * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
> failing in the jms transport systests - JIRA?
>  * ./systests/container-integration/grizzly skipped -
> https://issues.apache.org/jira/browse/CXF-8716
>  * jaxrs systests skipped - JIRA?
>  * systests/wsdl_maven/codegen skipped - JIRA?
>  * maven-plugins/wadl2java-plugin - JIRA?
>  * maven-plugins/java2swagger-plugin - JIRA?
>
> Colm.
>
> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
> >
> > Hi Jim,
> >
> > No objections from my side, thank you.
> >
> > Best Regards,
> >     Andriy Redko
> >
> > On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
> >>>> 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
> >>>> 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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <
> drreta@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 <
> mail2jimma@gmail.com>
> >>>>> >> >>>>> wrote:
> >>>>> >> >>>>>
> >>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
> >>>>> >> >>>>> >>
> >>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
> drreta@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 <
> >>>>> >> mail2jimma@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 <
> >>>>> >> drreta@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 <
> >>>>> >> >>>>> drreta@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 <
> >>>>> >> >>>>> mail2jimma@gmail.com>
> >>>>> >> >>>>> >>> >> > wrote:
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy
> Redko <
> >>>>> >> >>>>> >>> drreta@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 <
> >>>>> >> >>>>> >>> drreta@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 <
> >>>>> >> >>>>> >>> >> > drreta@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 <
> >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim
> Ma <
> >>>>> >> >>>>> >>> mail2jimma@gmail.com>
> >>>>> >> >>>>> >>> >> > a
> >>>>> >> >>>>> >>> >> > >> >>> écrit
> >>>>> >> >>>>> >>> >> > >> >>> >> :
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM
> Romain
> >>>>> >> >>>>> Manni-Bucau <
> >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39,
> Jim Ma <
> >>>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
> >>>>> >> >>>>> >>> >> > >> a
> >>>>> >> >>>>> >>> >> > >> >>> >> écrit :
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
> Romain
> >>>>> >> >>>>> >>> Manni-Bucau <
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> >
> >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45,
> Andriy
> >>>>> >> Redko
> >>>>> >> >>>>> <
> >>>>> >> >>>>> >>> >> > >> drreta@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 <
> >>>>> >> rmannibucau@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
> >>>>> >> >>>>> >>> <
> >>>>> >> >>>>> >>> >> > >> >>> >> drreta@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]
> >>>>> >> >>>>> >>>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Colm O hEigeartaigh <co...@apache.org>]

Hi,

No objection from me either. Apart from OSGi, could we make sure that
all the gaps are recorded in JIRA?

 * Test failures in cxf-rt-mp-client -
https://issues.apache.org/jira/browse/CXF-8758
 * Test failures in
cxf-systests-transports-undertow,cxf-systests-jaxws (websocket
related) - https://issues.apache.org/jira/browse/CXF-8717
 * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is
failing in the jms transport systests - JIRA?
 * ./systests/container-integration/grizzly skipped -
https://issues.apache.org/jira/browse/CXF-8716
 * jaxrs systests skipped - JIRA?
 * systests/wsdl_maven/codegen skipped - JIRA?
 * maven-plugins/wadl2java-plugin - JIRA?
 * maven-plugins/java2swagger-plugin - JIRA?

Colm.

On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <dr...@gmail.com> wrote:
>
> Hi Jim,
>
> No objections from my side, thank you.
>
> Best Regards,
>     Andriy Redko
>
> On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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.
>>>> 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
>>>> 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 <dr...@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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>> >> >>>>> wrote:
>>>>> >> >>>>>
>>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>>>>> >> >>>>> >>
>>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>>>>> >> mail2jimma@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 <
>>>>> >> drreta@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 <
>>>>> >> >>>>> drreta@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 <
>>>>> >> >>>>> mail2jimma@gmail.com>
>>>>> >> >>>>> >>> >> > wrote:
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>> >> >>>>> >>> drreta@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 <
>>>>> >> >>>>> >>> drreta@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 <
>>>>> >> >>>>> >>> >> > drreta@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 <
>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>> >> >>>>> >>> mail2jimma@gmail.com>
>>>>> >> >>>>> >>> >> > a
>>>>> >> >>>>> >>> >> > >> >>> écrit
>>>>> >> >>>>> >>> >> > >> >>> >> :
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>> >> >>>>> Manni-Bucau <
>>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>>>>> >> >>>>> >>> >> > >> a
>>>>> >> >>>>> >>> >> > >> >>> >> écrit :
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>> >> >>>>> >>> Manni-Bucau <
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> >
>>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>>>>> >> Redko
>>>>> >> >>>>> <
>>>>> >> >>>>> >>> >> > >> drreta@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 <
>>>>> >> rmannibucau@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
>>>>> >> >>>>> >>> <
>>>>> >> >>>>> >>> >> > >> >>> >> drreta@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]
>>>>> >> >>>>> >>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andrey Redko <dr...@gmail.com>]

Hi Jim,

No objections from my side, thank you.

Best Regards,
    Andriy Redko

On Tue, Sep 27, 2022, 9:31 PM Jim Ma <ma...@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 <dr...@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 <ma...@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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <dr...@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 <
>>>> mail2jimma@gmail.com>
>>>> >> >>>>> wrote:
>>>> >> >>>>>
>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>>>> >> >>>>> >>
>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>>>> drreta@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 <
>>>> >> mail2jimma@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 <
>>>> >> drreta@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 <
>>>> >> >>>>> drreta@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 <
>>>> >> >>>>> mail2jimma@gmail.com>
>>>> >> >>>>> >>> >> > wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>> >> >>>>> >>> drreta@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 <
>>>> >> >>>>> >>> drreta@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 <
>>>> >> >>>>> >>> >> > drreta@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 <
>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>> >> >>>>> >>> mail2jimma@gmail.com>
>>>> >> >>>>> >>> >> > a
>>>> >> >>>>> >>> >> > >> >>> écrit
>>>> >> >>>>> >>> >> > >> >>> >> :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM
>>>> Romain
>>>> >> >>>>> Manni-Bucau <
>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim
>>>> Ma <
>>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>>>> >> >>>>> >>> >> > >> a
>>>> >> >>>>> >>> >> > >> >>> >> écrit :
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>>>> Romain
>>>> >> >>>>> >>> Manni-Bucau <
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> >
>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45,
>>>> Andriy
>>>> >> Redko
>>>> >> >>>>> <
>>>> >> >>>>> >>> >> > >> drreta@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 <
>>>> >> rmannibucau@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
>>>> >> >>>>> >>> <
>>>> >> >>>>> >>> >> > >> >>> >> drreta@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>
>>>
>>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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 <dr...@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 <ma...@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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <dr...@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 <
>>> mail2jimma@gmail.com>
>>> >> >>>>> wrote:
>>> >> >>>>>
>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>>> >> >>>>> >>
>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>>> drreta@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 <
>>> >> mail2jimma@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 <
>>> >> drreta@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 <
>>> >> >>>>> drreta@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 <
>>> >> >>>>> mail2jimma@gmail.com>
>>> >> >>>>> >>> >> > wrote:
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>> >> >>>>> >>> drreta@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
>>> <
>>> >> >>>>> >>> drreta@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 <
>>> >> >>>>> >>> >> > drreta@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 <
>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>> >> >>>>> >>> mail2jimma@gmail.com>
>>> >> >>>>> >>> >> > a
>>> >> >>>>> >>> >> > >> >>> écrit
>>> >> >>>>> >>> >> > >> >>> >> :
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>> >> >>>>> Manni-Bucau <
>>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma
>>> <
>>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>>> >> >>>>> >>> >> > >> a
>>> >> >>>>> >>> >> > >> >>> >> écrit :
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>>> Romain
>>> >> >>>>> >>> Manni-Bucau <
>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> >
>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45,
>>> Andriy
>>> >> Redko
>>> >> >>>>> <
>>> >> >>>>> >>> >> > >> drreta@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 <
>>> >> rmannibucau@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
>>> >> >>>>> >>> <
>>> >> >>>>> >>> >> > >> >>> >> drreta@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>
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andrey Redko <dr...@gmail.com>]

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 <ma...@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 <dr...@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 <dr...@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 <ma...@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.fang@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 <ma...@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 <dr...@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 <
>> mail2jimma@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>
>> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >> >>>>> >>
>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <
>> drreta@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 <
>> >> mail2jimma@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 <
>> >> drreta@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 <
>> >> >>>>> drreta@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 <
>> >> >>>>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> drreta@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 <
>> >> >>>>> >>> >> > drreta@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 <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >> >>>>> >>> mail2jimma@gmail.com>
>> >> >>>>> >>> >> > a
>> >> >>>>> >>> >> > >> >>> écrit
>> >> >>>>> >>> >> > >> >>> >> :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >> >>>>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >> >>>>> >>> >> > mail2jimma@gmail.com>
>> >> >>>>> >>> >> > >> a
>> >> >>>>> >>> >> > >> >>> >> écrit :
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM
>> Romain
>> >> >>>>> >>> Manni-Bucau <
>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> >
>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>> >> Redko
>> >> >>>>> <
>> >> >>>>> >>> >> > >> drreta@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 <
>> >> rmannibucau@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
>> >> >>>>> >>> <
>> >> >>>>> >>> >> > >> >>> >> drreta@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>
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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 <dr...@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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <mail2jimma@gmail.com
> >
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
> >> >>>>> >>
> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <drreta@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 <
> >> mail2jimma@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 <
> >> drreta@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 <
> >> >>>>> drreta@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 <
> >> >>>>> mail2jimma@gmail.com>
> >> >>>>> >>> >> > wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >> >>>>> >>> drreta@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 <
> >> >>>>> >>> drreta@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 <
> >> >>>>> >>> >> > drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >> >>>>> >>> mail2jimma@gmail.com>
> >> >>>>> >>> >> > a
> >> >>>>> >>> >> > >> >>> écrit
> >> >>>>> >>> >> > >> >>> >> :
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >> >>>>> Manni-Bucau <
> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >> >>>>> >>> >> > mail2jimma@gmail.com>
> >> >>>>> >>> >> > >> a
> >> >>>>> >>> >> > >> >>> >> écrit :
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >> >>>>> >>> Manni-Bucau <
> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
> >> Redko
> >> >>>>> <
> >> >>>>> >>> >> > >> drreta@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 <
> >> rmannibucau@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
> >> >>>>> >>> <
> >> >>>>> >>> >> > >> >>> >> drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@gmail.com%3E
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [3]
> >> >>>>> >>> https://github.com/apache/cxf/pull/737
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [4]
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >>
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >>
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>>
> >> >>>>> >>> >> > >> >>> >> >>
> >> >>>>> >>> >> > >> >>> >>
> >> >>>>> >>> >> > >> >>>
> >> >>>>> >>> >> > >>
> >> >>>>> >>> >> >
> >> >>>>> >>>
> >> >>>>>
> >>
> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> Best Regards,
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>     Andriy Redko
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>>
> >> >>>>> >>>
> >> >>>>>
> >> >>>>>
> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <mail2jimma@gmail.com
> >
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>> >> Thanks Andriy too for driving this and moving forward !
> >> >>>>> >>
> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <drreta@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 <
> >> mail2jimma@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 <
> >> drreta@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 <
> >> >>>>> drreta@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 <
> >> >>>>> mail2jimma@gmail.com>
> >> >>>>> >>> >> > wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >> >>>>> >>> drreta@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 <
> >> >>>>> >>> drreta@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 <
> >> >>>>> >>> >> > drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> >>>>> >>> >> > >> >>> >> >> JM> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >> >>>>> >>> mail2jimma@gmail.com>
> >> >>>>> >>> >> > a
> >> >>>>> >>> >> > >> >>> écrit
> >> >>>>> >>> >> > >> >>> >> :
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >> >>>>> Manni-Bucau <
> >> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> >>>>> >>> >> > >> >>> >> >> >>> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >> >>>>> >>> >> > mail2jimma@gmail.com>
> >> >>>>> >>> >> > >> a
> >> >>>>> >>> >> > >> >>> >> écrit :
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >> >>>>> >>> Manni-Bucau <
> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
> >> Redko
> >> >>>>> <
> >> >>>>> >>> >> > >> drreta@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 <
> >> rmannibucau@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
> >> >>>>> >>> <
> >> >>>>> >>> >> > >> >>> >> drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> drreta@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 <
> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
> >> >>>>> >>> >> >
> >> >>>>> >>> >> >
> >> >>>>> >>>
> >> >>>>> >>>
> >> >>>>>
> >> >>>>>
> >>
> >>
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >>>>> >>
>> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>> mail2jimma@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 <
>> drreta@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 <
>> >>>>> drreta@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 <
>> >>>>> mail2jimma@gmail.com>
>> >>>>> >>> >> > wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >>>>> >>> drreta@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 <
>> >>>>> >>> drreta@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 <
>> >>>>> >>> >> > drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >>>>> >>> mail2jimma@gmail.com>
>> >>>>> >>> >> > a
>> >>>>> >>> >> > >> >>> écrit
>> >>>>> >>> >> > >> >>> >> :
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >>>>> Manni-Bucau <
>> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >>>>> >>> >> > mail2jimma@gmail.com>
>> >>>>> >>> >> > >> a
>> >>>>> >>> >> > >> >>> >> écrit :
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>> >>>>> >>> Manni-Bucau <
>> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>> Redko
>> >>>>> <
>> >>>>> >>> >> > >> drreta@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 <
>> rmannibucau@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
>> >>>>> >>> <
>> >>>>> >>> >> > >> >>> >> drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@gmail.com%3E
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [3]
>> >>>>> >>> https://github.com/apache/cxf/pull/737
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [4]
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >>
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >>
>> >>>>> >>> >> > >> >>> >> >> >>>>>>>
>> >>>>> >>> >> > >> >>> >> >>
>> >>>>> >>> >> > >> >>> >>
>> >>>>> >>> >> > >> >>>
>> >>>>> >>> >> > >>
>> >>>>> >>> >> >
>> >>>>> >>>
>> >>>>>
>> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> Best Regards,
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>     Andriy Redko
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>>
>> >>>>> >>>
>> >>>>>
>> >>>>>
>> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>> >> Thanks Andriy too for driving this and moving forward !
>> >>>>> >>
>> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
>> mail2jimma@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 <
>> drreta@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 <
>> >>>>> drreta@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 <
>> >>>>> mail2jimma@gmail.com>
>> >>>>> >>> >> > wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >>>>> >>> drreta@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 <
>> >>>>> >>> drreta@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 <
>> >>>>> >>> >> > drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >>> >> > >> >>> >> >> JM> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >>>>> >>> mail2jimma@gmail.com>
>> >>>>> >>> >> > a
>> >>>>> >>> >> > >> >>> écrit
>> >>>>> >>> >> > >> >>> >> :
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >>>>> Manni-Bucau <
>> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>>>> >>> >> > >> >>> >> >> >>> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >>>>> >>> >> > mail2jimma@gmail.com>
>> >>>>> >>> >> > >> a
>> >>>>> >>> >> > >> >>> >> écrit :
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>> >>>>> >>> Manni-Bucau <
>> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
>> Redko
>> >>>>> <
>> >>>>> >>> >> > >> drreta@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 <
>> rmannibucau@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
>> >>>>> >>> <
>> >>>>> >>> >> > >> >>> >> drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> drreta@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 <
>> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >>>>> >>> >> >
>> >>>>> >>> >> >
>> >>>>> >>>
>> >>>>> >>>
>> >>>>>
>> >>>>>
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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

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



On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <dr...@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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> >> Thanks Andriy too for driving this and moving forward !
> >>>>> >>
> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
> mail2jimma@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 <
> drreta@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 <
> >>>>> drreta@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 <
> >>>>> mail2jimma@gmail.com>
> >>>>> >>> >> > wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >>>>> >>> drreta@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 <
> >>>>> >>> drreta@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 <
> >>>>> >>> >> > drreta@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 <
> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >>> >> > >> >>> >> >> JM> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >>>>> >>> mail2jimma@gmail.com>
> >>>>> >>> >> > a
> >>>>> >>> >> > >> >>> écrit
> >>>>> >>> >> > >> >>> >> :
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >>>>> Manni-Bucau <
> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >>> >> > >> >>> >> >> >>> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >>>>> >>> >> > mail2jimma@gmail.com>
> >>>>> >>> >> > >> a
> >>>>> >>> >> > >> >>> >> écrit :
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >>>>> >>> Manni-Bucau <
> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
> Redko
> >>>>> <
> >>>>> >>> >> > >> drreta@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 <
> rmannibucau@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
> >>>>> >>> <
> >>>>> >>> >> > >> >>> >> drreta@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 <
> >>>>> >>> >> > >> >>> >> >> drreta@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 <
> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@gmail.com%3E
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [3]
> >>>>> >>> https://github.com/apache/cxf/pull/737
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [4]
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >>
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >>
> >>>>> >>> >> > >> >>> >> >> >>>>>>>
> >>>>> >>> >> > >> >>> >> >>
> >>>>> >>> >> > >> >>> >>
> >>>>> >>> >> > >> >>>
> >>>>> >>> >> > >>
> >>>>> >>> >> >
> >>>>> >>>
> >>>>>
> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> Best Regards,
> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>     Andriy Redko
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>>
> >>>>> >>>
> >>>>>
> >>>>>
> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> >> Thanks Andriy too for driving this and moving forward !
> >>>>> >>
> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
> mail2jimma@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 <
> drreta@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 <
> >>>>> drreta@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 <
> >>>>> mail2jimma@gmail.com>
> >>>>> >>> >> > wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >>>>> >>> drreta@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 <
> >>>>> >>> drreta@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 <
> >>>>> >>> >> > drreta@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 <
> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >>> >> > >> >>> >> >> JM> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >>>>> >>> mail2jimma@gmail.com>
> >>>>> >>> >> > a
> >>>>> >>> >> > >> >>> écrit
> >>>>> >>> >> > >> >>> >> :
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >>>>> Manni-Bucau <
> >>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>>>> >>> >> > >> >>> >> >> >>> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >>>>> >>> >> > mail2jimma@gmail.com>
> >>>>> >>> >> > >> a
> >>>>> >>> >> > >> >>> >> écrit :
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >>>>> >>> Manni-Bucau <
> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy
> Redko
> >>>>> <
> >>>>> >>> >> > >> drreta@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 <
> rmannibucau@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
> >>>>> >>> <
> >>>>> >>> >> > >> >>> >> drreta@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 <
> >>>>> >>> >> > >> >>> >> >> drreta@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 <
> >>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
> >>>>> >>> >> >
> >>>>> >>> >> >
> >>>>> >>>
> >>>>> >>>
> >>>>>
> >>>>>
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> >> Thanks Andriy too for driving this and moving forward !
>>>>> >>
>>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>>>>> drreta@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 <
>>>>> mail2jimma@gmail.com>
>>>>> >>> >> > wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>> >>> drreta@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 <
>>>>> >>> drreta@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 <
>>>>> >>> >> > drreta@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 <
>>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>> >>> mail2jimma@gmail.com>
>>>>> >>> >> > a
>>>>> >>> >> > >> >>> écrit
>>>>> >>> >> > >> >>> >> :
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>> Manni-Bucau <
>>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>> >>> >> > mail2jimma@gmail.com>
>>>>> >>> >> > >> a
>>>>> >>> >> > >> >>> >> écrit :
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>> >>> Manni-Bucau <
>>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko
>>>>> <
>>>>> >>> >> > >> drreta@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 <rm...@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
>>>>> >>> <
>>>>> >>> >> > >> >>> >> drreta@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 <
>>>>> >>> >> > >> >>> >> >> drreta@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 <
>>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@gmail.com%3E
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [3]
>>>>> >>> https://github.com/apache/cxf/pull/737
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> [4]
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >>
>>>>> >>> >> > >> >>> >> >> >>>>>>> >>
>>>>> >>> >> > >> >>> >> >> >>>>>>>
>>>>> >>> >> > >> >>> >> >>
>>>>> >>> >> > >> >>> >>
>>>>> >>> >> > >> >>>
>>>>> >>> >> > >>
>>>>> >>> >> >
>>>>> >>>
>>>>> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >> Best Regards,
>>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> >>     Andriy Redko
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>>
>>>>> >>>
>>>>>
>>>>>
JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> >> Thanks Andriy too for driving this and moving forward !
>>>>> >>
>>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>>>>> drreta@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 <
>>>>> mail2jimma@gmail.com>
>>>>> >>> >> > wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>>> >>> drreta@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 <
>>>>> >>> drreta@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 <
>>>>> >>> >> > drreta@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 <
>>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>>> >>> mail2jimma@gmail.com>
>>>>> >>> >> > a
>>>>> >>> >> > >> >>> écrit
>>>>> >>> >> > >> >>> >> :
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>>> Manni-Bucau <
>>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>> >>> >> > mail2jimma@gmail.com>
>>>>> >>> >> > >> a
>>>>> >>> >> > >> >>> >> écrit :
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>>> >>> Manni-Bucau <
>>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko
>>>>> <
>>>>> >>> >> > >> drreta@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 <rm...@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
>>>>> >>> <
>>>>> >>> >> > >> >>> >> drreta@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 <
>>>>> >>> >> > >> >>> >> >> drreta@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 <
>>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>>
>>>>> >>>
>>>>>
>>>>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

Hi Andriy,
It looks like we still have to wait for the other dependency jakarta
support available, like brave's new release to include this change :
https://github.com/openzipkin/brave/pull/1344.  Do you see any other
dependencies that haven't been released yet except OSGI and Karaf ?

Thanks,
Jim


On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>> wrote:
>>>>
>>>> >> Thanks Andriy too for driving this and moving forward !
>>>> >>
>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>>>> drreta@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 <
>>>> mail2jimma@gmail.com>
>>>> >>> >> > wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>> >>> drreta@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 <
>>>> >>> drreta@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 <
>>>> >>> >> > drreta@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 <
>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>> >>> mail2jimma@gmail.com>
>>>> >>> >> > a
>>>> >>> >> > >> >>> écrit
>>>> >>> >> > >> >>> >> :
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>> Manni-Bucau <
>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>> >>> >> > mail2jimma@gmail.com>
>>>> >>> >> > >> a
>>>> >>> >> > >> >>> >> écrit :
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>> >>> Manni-Bucau <
>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko
>>>> <
>>>> >>> >> > >> drreta@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 <rm...@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
>>>> >>> <
>>>> >>> >> > >> >>> >> drreta@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 <
>>>> >>> >> > >> >>> >> >> drreta@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 <
>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>>>> >>> >> >
>>>> >>> >> >
>>>> >>>
>>>> >>>
>>>>
>>>>
On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <ma...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>> wrote:
>>>>
>>>> >> Thanks Andriy too for driving this and moving forward !
>>>> >>
>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>>>> drreta@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 <
>>>> mail2jimma@gmail.com>
>>>> >>> >> > wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>>> >>> drreta@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 <
>>>> >>> drreta@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 <
>>>> >>> >> > drreta@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 <
>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >>> >> > >> >>> >> >> JM> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>>> >>> mail2jimma@gmail.com>
>>>> >>> >> > a
>>>> >>> >> > >> >>> écrit
>>>> >>> >> > >> >>> >> :
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>> Manni-Bucau <
>>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>>> >>> >> > >> >>> >> >> >>> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>> >>> >> > mail2jimma@gmail.com>
>>>> >>> >> > >> a
>>>> >>> >> > >> >>> >> écrit :
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>>> >>> Manni-Bucau <
>>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko
>>>> <
>>>> >>> >> > >> drreta@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 <rm...@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
>>>> >>> <
>>>> >>> >> > >> >>> >> drreta@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 <
>>>> >>> >> > >> >>> >> >> drreta@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 <
>>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>>>> >>> >> >
>>>> >>> >> >
>>>> >>>
>>>> >>>
>>>>
>>>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Freeman Fang <fr...@gmail.com>]

+1 for this way, it's much easier.
Thanks!

Freeman


On Fri, Sep 9, 2022 at 3:55 PM Andriy Redko <dr...@gmail.com> wrote:

> 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 <dr...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
> >> >>>> wrote:
> >> >>>>>> Thanks Andriy too for driving this and moving forward !
> >>
> >> >>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <
> mail2jimma@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 <
> drreta@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 <
> >> drreta@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 <
> >> >>>> mail2jimma@gmail.com>
> >> >>>>>>>>>> wrote:
> >>
> >> >>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >>
> >> drreta@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 <
> >>
> >> drreta@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 <
> >> drreta@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 <
> >> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
> >> JM>>>>>>>>>>>>>>>>>>>> wrote:
> >>
> >> >>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >>
> >> >>>>>>> mail2jimma@gmail.com>
> >> >>>>>>>>>> a
> >> >>>>>>>>>>>>>>> écrit
> >> >>>>>>>>>>>>>>>>> :
> >>
> >> >>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >> >>>> Manni-Bucau <
> >> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
> >> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>
> >> >>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >> >>>>>>>>>> mail2jimma@gmail.com>
> >> >>>>>>>>>>>> a
> >> >>>>>>>>>>>>>>>>> écrit :
> >> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >>
> >> >>>>>>> Manni-Bucau <
> >> >>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:
> >>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> >>
> >> drreta@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 <rm...@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
> >> >>>>>>> <
> >> drreta@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 <
> >> drreta@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 <
> >> drreta@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.20201226124316@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
> >>
> >>
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <dr...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>> >>>> wrote:
>> >>>>>> Thanks Andriy too for driving this and moving forward !
>>
>> >>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>> drreta@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 <
>> >>>> mail2jimma@gmail.com>
>> >>>>>>>>>> wrote:
>>
>> >>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>
>> drreta@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 <
>>
>> drreta@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 <
>> drreta@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 <
>> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>> JM>>>>>>>>>>>>>>>>>>>> wrote:
>>
>> >>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>
>> >>>>>>> mail2jimma@gmail.com>
>> >>>>>>>>>> a
>> >>>>>>>>>>>>>>> écrit
>> >>>>>>>>>>>>>>>>> :
>>
>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> >>>> Manni-Bucau <
>> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>> wrote:
>>
>> >>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >>>>>>>>>> mail2jimma@gmail.com>
>> >>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>>> écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>
>> >>>>>>> Manni-Bucau <
>> >>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:
>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>>
>> drreta@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 <rm...@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
>> >>>>>>> <
>> drreta@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 <
>> drreta@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 <
>> drreta@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.20201226124316@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
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

Hi Andriy,
From what I looked at last time, it seems it's difficult to decouple these
osgi/karaf integration code from cxf core
and create a new project to put it into a separate repository. IMO, we can
create a branch before we
remove these integration codes, and later we can look at this branch to
restore the osgi/integration code when
osgi jakarta support is available.  Your thoughts?

Thanks,
Jim

On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko <dr...@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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
> >>>> wrote:
> >>>>>> Thanks Andriy too for driving this and moving forward !
>
> >>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
> drreta@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 <
> >>>> mail2jimma@gmail.com>
> >>>>>>>>>> wrote:
>
> >>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>
> drreta@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 <
>
> drreta@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 <
> drreta@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 <
> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
> JM>>>>>>>>>>>>>>>>>>>> wrote:
>
> >>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>
> >>>>>>> mail2jimma@gmail.com>
> >>>>>>>>>> a
> >>>>>>>>>>>>>>> écrit
> >>>>>>>>>>>>>>>>> :
>
> >>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> >>>> Manni-Bucau <
> >>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
>
> >>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >>>>>>>>>> mail2jimma@gmail.com>
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>
> >>>>>>> Manni-Bucau <
> >>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:
>
> >>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>
> drreta@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 <rm...@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
> >>>>>>> <
> drreta@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 <
> drreta@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 <
> drreta@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.20201226124316@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
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>>> wrote:
>>>>>> Thanks Andriy too for driving this and moving forward !

>>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
drreta@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 <
>>>> mail2jimma@gmail.com>
>>>>>>>>>> wrote:

>>>>>>>>>>>>>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <

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

drreta@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 <
drreta@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 <
>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
JM>>>>>>>>>>>>>>>>>>>> wrote:

>>>>>>>>>>>>>>>>>>>>> Le ven. 3 sept. 2021 à 11:30, Jim Ma <

>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>> a
>>>>>>>>>>>>>>> écrit
>>>>>>>>>>>>>>>>> :

>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:

>>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>>>>>>>>> mail2jimma@gmail.com>
>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain

>>>>>>> Manni-Bucau <
>>>>>>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com> wrote:

>>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <

drreta@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 <rm...@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
>>>>>>> <
drreta@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 <
drreta@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 <
drreta@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.20201226124316@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

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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 <fr...@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 <ma...@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 <dr...@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 <ma...@gmail.com>
>>> wrote:
>>>
>>> >> Thanks Andriy too for driving this and moving forward !
>>> >>
>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>>> drreta@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 <
>>> mail2jimma@gmail.com>
>>> >>> >> > wrote:
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>> >>> drreta@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 <
>>> >>> drreta@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 <
>>> >>> >> > drreta@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 <
>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >>> >> > >> >>> >> >> JM> wrote:
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>> >>> mail2jimma@gmail.com>
>>> >>> >> > a
>>> >>> >> > >> >>> écrit
>>> >>> >> > >> >>> >> :
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>>> Manni-Bucau <
>>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >>> >> > >> >>> >> >> >>> wrote:
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>> >>> >> > mail2jimma@gmail.com>
>>> >>> >> > >> a
>>> >>> >> > >> >>> >> écrit :
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>> >>> Manni-Bucau <
>>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>>> >>> >> > >> drreta@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 <rm...@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
>>> >>> <
>>> >>> >> > >> >>> >> drreta@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 <
>>> >>> >> > >> >>> >> >> drreta@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 <
>>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>>> >>> >> >
>>> >>> >> >
>>> >>>
>>> >>>
>>>
>>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Freeman Fang <fr...@gmail.com>]

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 <ma...@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 <dr...@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 <ma...@gmail.com> wrote:
>>
>> >> Thanks Andriy too for driving this and moving forward !
>> >>
>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
>> drreta@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 <
>> mail2jimma@gmail.com>
>> >>> >> > wrote:
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> >>> drreta@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 <
>> >>> drreta@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 <
>> >>> >> > drreta@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 <
>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>> >> > >> >>> >> >> JM> wrote:
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> >>> mail2jimma@gmail.com>
>> >>> >> > a
>> >>> >> > >> >>> écrit
>> >>> >> > >> >>> >> :
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
>> Manni-Bucau <
>> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >>> >> > >> >>> >> >> >>> wrote:
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >>> >> > mail2jimma@gmail.com>
>> >>> >> > >> a
>> >>> >> > >> >>> >> écrit :
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>> >>> Manni-Bucau <
>> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> >>> >> > >> drreta@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 <rm...@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
>> >>> <
>> >>> >> > >> >>> >> drreta@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 <
>> >>> >> > >> >>> >> >> drreta@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 <
>> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >>> >> >
>> >>> >> >
>> >>>
>> >>>
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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 <dr...@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 <ma...@gmail.com> wrote:
>
> >> Thanks Andriy too for driving this and moving forward !
> >>
> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <
> drreta@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 <
> mail2jimma@gmail.com>
> >>> >> > wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
> >>> drreta@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 <
> >>> drreta@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 <
> >>> >> > drreta@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 <
> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>> >> > >> >>> >> >> JM> wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> >>> mail2jimma@gmail.com>
> >>> >> > a
> >>> >> > >> >>> écrit
> >>> >> > >> >>> >> :
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain
> Manni-Bucau <
> >>> >> > >> >>> >> >> rmannibucau@gmail.com>
> >>> >> > >> >>> >> >> >>> wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >>> >> > mail2jimma@gmail.com>
> >>> >> > >> a
> >>> >> > >> >>> >> écrit :
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
> >>> Manni-Bucau <
> >>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> >>> >> > >> drreta@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 <rm...@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
> >>> <
> >>> >> > >> >>> >> drreta@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 <
> >>> >> > >> >>> >> >> drreta@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 <
> >>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
> >>> >> >
> >>> >> >
> >>>
> >>>
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <ma...@gmail.com> wrote:

>> Thanks Andriy too for driving this and moving forward !
>>
>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>>> drreta@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 <
>>> drreta@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 <
>>> >> > drreta@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 <
>>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >> > >> >>> >> >> JM> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>>> mail2jimma@gmail.com>
>>> >> > a
>>> >> > >> >>> écrit
>>> >> > >> >>> >> :
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>>> >> > >> >>> >> >> rmannibucau@gmail.com>
>>> >> > >> >>> >> >> >>> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>>> >> > mail2jimma@gmail.com>
>>> >> > >> a
>>> >> > >> >>> >> écrit :
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>>> Manni-Bucau <
>>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>>> >> > >> drreta@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 <rm...@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
>>> <
>>> >> > >> >>> >> drreta@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 <
>>> >> > >> >>> >> >> drreta@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 <
>>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>>> >> >
>>> >> >
>>>
>>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

After we merged the jakarta branch to default branch main branch,  do we
need to create some
plan to do a future 4.x release?

There are a couple of to-do things under
https://issues.apache.org/jira/browse/CXF-8371 umberbralla,
and for some of them we can't do more things because of the jakarta
dependency missing. It seems that some of the dependencies won't
have the jakarta namespace artifact released in the near future.  Should we
have some milestone/alpha release
before all these dependencies are available ?  And if we want to do a
milestone release, what do you think we should have in
this 4.0.0-M1 release ?


Thanks,
Jim



On Wed, Jun 22, 2022 at 10:02 AM Jim Ma <ma...@gmail.com> wrote:

> Thanks Andriy too for driving this and moving forward !
>
> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <
>> drreta@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 <
>> drreta@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 <
>> >> > drreta@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 <
>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> > >> >>> >> >> JM> wrote:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
>> mail2jimma@gmail.com>
>> >> > a
>> >> > >> >>> écrit
>> >> > >> >>> >> :
>> >> >
>> >> >
>> >> >
>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >> > >> >>> >> >> rmannibucau@gmail.com>
>> >> > >> >>> >> >> >>> wrote:
>> >> >
>> >> >
>> >> >
>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> >> > mail2jimma@gmail.com>
>> >> > >> a
>> >> > >> >>> >> écrit :
>> >> >
>> >> >
>> >> >
>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain
>> Manni-Bucau <
>> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> >> > >> drreta@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 <rm...@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
>> <
>> >> > >> >>> >> drreta@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 <
>> >> > >> >>> >> >> drreta@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 <
>> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >> >
>> >> >
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

Thanks Andriy too for driving this and moving forward !

On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko <dr...@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 <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
> >> > wrote:
> >> >
> >> >
> >> >
> >> >
> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <drreta@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 <
> drreta@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 <
> >> > drreta@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 <
> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> > >> >>> >> >> JM> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <
> mail2jimma@gmail.com>
> >> > a
> >> > >> >>> écrit
> >> > >> >>> >> :
> >> >
> >> >
> >> >
> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> >> > >> >>> >> >> rmannibucau@gmail.com>
> >> > >> >>> >> >> >>> wrote:
> >> >
> >> >
> >> >
> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> >> > mail2jimma@gmail.com>
> >> > >> a
> >> > >> >>> >> écrit :
> >> >
> >> >
> >> >
> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau
> <
> >> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> >> > >> drreta@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 <rm...@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 <
> >> > >> >>> >> drreta@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 <
> >> > >> >>> >> >> drreta@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 <
> >> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
> >> >
> >> >
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
>> > wrote:
>> >
>> >
>> >
>> >
>> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <
>> > drreta@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 <
>> > >> >>> >> >> rmannibucau@gmail.com>
>> > >> >>> >> >> JM> wrote:
>> >
>> >
>> >
>> >
>> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com>
>> > a
>> > >> >>> écrit
>> > >> >>> >> :
>> >
>> >
>> >
>> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> > >> >>> >> >> rmannibucau@gmail.com>
>> > >> >>> >> >> >>> wrote:
>> >
>> >
>> >
>> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> > mail2jimma@gmail.com>
>> > >> a
>> > >> >>> >> écrit :
>> >
>> >
>> >
>> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >
>> >
>> >
>> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> > >> drreta@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 <rm...@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 <
>> > >> >>> >> drreta@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 <
>> > >> >>> >> >> drreta@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 <
>> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >
>> >

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Thanks guys, the branch is created: https://github.com/apache/cxf/tree/3.6.x-fixes

Best Regards,
    Andriy Redko

COh> +1 from me.

COh> Colm.

COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
>> > wrote:
>> >
>> >
>> >
>> >
>> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <
>> > drreta@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 <
>> > >> >>> >> >> rmannibucau@gmail.com>
>> > >> >>> >> >> JM> wrote:
>> >
>> >
>> >
>> >
>> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com>
>> > a
>> > >> >>> écrit
>> > >> >>> >> :
>> >
>> >
>> >
>> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> > >> >>> >> >> rmannibucau@gmail.com>
>> > >> >>> >> >> >>> wrote:
>> >
>> >
>> >
>> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
>> > mail2jimma@gmail.com>
>> > >> a
>> > >> >>> >> écrit :
>> >
>> >
>> >
>> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>> >
>> >
>> >
>> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> > >> drreta@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 <rm...@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 <
>> > >> >>> >> drreta@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 <
>> > >> >>> >> >> drreta@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 <
>> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>> >
>> >

Re: [DISCUSS] CXF 3.5.x and beyond

[Colm O hEigeartaigh <co...@apache.org>]

+1 from me.

Colm.

On Thu, May 26, 2022 at 2:40 AM Jim Ma <ma...@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 <dr...@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 <dr...@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 <ma...@gmail.com>
> > wrote:
> >
> >
> >
> >
> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <
> > drreta@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 <
> > >> >>> >> >> rmannibucau@gmail.com>
> > >> >>> >> >> JM> wrote:
> >
> >
> >
> >
> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com>
> > a
> > >> >>> écrit
> > >> >>> >> :
> >
> >
> >
> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> > >> >>> >> >> rmannibucau@gmail.com>
> > >> >>> >> >> >>> wrote:
> >
> >
> >
> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> > mail2jimma@gmail.com>
> > >> a
> > >> >>> >> écrit :
> >
> >
> >
> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
> > >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
> >
> >
> >
> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> > >> drreta@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 <rm...@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 <
> > >> >>> >> drreta@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 <
> > >> >>> >> >> drreta@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 <
> > >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
> >
> >

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

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 <dr...@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 <dr...@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 <ma...@gmail.com>
> wrote:
>
>
>
>
> >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <
> drreta@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 <
> >> >>> >> >> rmannibucau@gmail.com>
> >> >>> >> >> JM> wrote:
>
>
>
>
> >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com>
> a
> >> >>> écrit
> >> >>> >> :
>
>
>
> >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> >> >>> >> >> rmannibucau@gmail.com>
> >> >>> >> >> >>> wrote:
>
>
>
> >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <
> mail2jimma@gmail.com>
> >> a
> >> >>> >> écrit :
>
>
>
> >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
> >> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>
>
>
> >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> >> drreta@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 <rm...@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 <
> >> >>> >> drreta@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 <
> >> >>> >> >> drreta@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 <
> >> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <dr...@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 <ma...@gmail.com> wrote:




>> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <dr...@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 <
>> >>> >> >> rmannibucau@gmail.com>
>> >>> >> >> JM> wrote:




>> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
>> >>> écrit
>> >>> >> :



>> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >>> >> >> rmannibucau@gmail.com>
>> >>> >> >> >>> wrote:



>> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com>
>> a
>> >>> >> écrit :



>> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:



>> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> drreta@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 <rm...@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 <
>> >>> >> drreta@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 <
>> >>> >> >> drreta@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 <
>> >>> >> >> >>>>>>> drreta@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.20201226124316@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

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

Hi Andriy,
I took some time to look at the CXF java11 support and spring decoupling
last week.
Here are some thoughts and initial work:
1) Use cross compile to support java11 . We can simply change
<cxf.jdk.version> in pom.xml to 11.
    This will allow the maven compiler plugin to build cxf with java11.
2) We can look at creating some separate modules for Spring relevant
code/configuration in the future. Ideally a small
 number of modules would be better and it will make it easy for users to
import spring relevant dependencies.
 Here is my initial work :  https://github.com/jimma/cxf/commits/spring
<https://github.com/jimma/cxf/commits/spring>. This only touches several
cxf modules, I am not
sure if this approach will get other blockers and issues.

Thanks,
Jim



On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <dr...@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 <ma...@gmail.com> wrote:
>
>
>
>
> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <dr...@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 <
> >>> >> >> rmannibucau@gmail.com>
> >>> >> >> JM> wrote:
>
>
>
>
> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
> >>> écrit
> >>> >> :
>
>
>
> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> >>> >> >> rmannibucau@gmail.com>
> >>> >> >> >>> wrote:
>
>
>
> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com>
> a
> >>> >> écrit :
>
>
>
> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>
>
>
> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> drreta@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 <rm...@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 <
> >>> >> drreta@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 <
> >>> >> >> drreta@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 <
> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

Hey Jim,

Yeah, it was just an example of some particular issue related to Spring usage
to scan classes, multiple alternative exists, just has to be done in non-breaking
way. But @Christian did the real work in that direction. Thanks!

Best Regards,
    Andriy Redko

JM> Thanks for the quick update , Andriy.

JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <dr...@gmail.com> wrote:

>> Hey Jim,

>> AFAIR this particular topic has popped up several times, a few issues
>> exist [1]


JM>  I am not sure if I understood this issue correctly : we now use
JM> spring utility class
JM>  to scan the resource/provider classes. If we make spring optional , this
JM> won't work
JM> and we have to create the Scanner like something with extcos ?

JM> From looking at the code，it only used by load resource by non spring class.
JM> Would it be enough
JM> if we replace this with load resource from classloader ?

JM> @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).


JM> @Christian  Do you still remember what's the main problem when you did this
JM> poc ?



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


JM>   +1. Let's see how much we can move forward to reduce the scope of the
JM> spring dependency.
JM>   I'll try to get more time to look at this task.



>> 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 <ma...@gmail.com> wrote:




>> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <dr...@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 <
>> >>> >> >> rmannibucau@gmail.com>
>> >>> >> >> JM> wrote:




>> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
>> >>> écrit
>> >>> >> :



>> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >>> >> >> rmannibucau@gmail.com>
>> >>> >> >> >>> wrote:



>> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com>
>> a
>> >>> >> écrit :



>> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:



>> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> drreta@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 <rm...@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 <
>> >>> >> drreta@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 <
>> >>> >> >> drreta@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 <
>> >>> >> >> >>>>>>> drreta@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.20201226124316@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

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

Thanks for the quick update , Andriy.

On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko <dr...@gmail.com> wrote:

> Hey Jim,
>
> AFAIR this particular topic has popped up several times, a few issues
> exist [1]


 I am not sure if I understood this issue correctly : we now use
spring utility class
 to scan the resource/provider classes. If we make spring optional , this
won't work
and we have to create the Scanner like something with extcos ?

From looking at the code，it only used by load resource by non spring class.
Would it be enough
if we replace this with load resource from classloader ?

@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).


@Christian  Do you still remember what's the main problem when you did this
poc ?


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

  +1. Let's see how much we can move forward to reduce the scope of the
spring dependency.
  I'll try to get more time to look at this task.


>
> 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 <ma...@gmail.com> wrote:
>
>
>
>
> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <dr...@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 <
> >>> >> >> rmannibucau@gmail.com>
> >>> >> >> JM> wrote:
>
>
>
>
> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
> >>> écrit
> >>> >> :
>
>
>
> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> >>> >> >> rmannibucau@gmail.com>
> >>> >> >> >>> wrote:
>
>
>
> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com>
> a
> >>> >> écrit :
>
>
>
> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
> >>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>
>
>
> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
> drreta@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 <rm...@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 <
> >>> >> drreta@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 <
> >>> >> >> drreta@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 <
> >>> >> >> >>>>>>> drreta@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.20201226124316@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
>
>

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko <dr...@gmail.com>]

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 <ma...@gmail.com> wrote:




>> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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 <dr...@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 <dr...@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 <
>>> >> >> rmannibucau@gmail.com>
>>> >> >> JM> wrote:




>>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
>>> écrit
>>> >> :



>>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>>> >> >> rmannibucau@gmail.com>
>>> >> >> >>> wrote:



>>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com> a
>>> >> écrit :



>>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>>> >> >> >>>>> rmannibucau@gmail.com> wrote:



>>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <dr...@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 <rm...@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 <
>>> >> drreta@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 <
>>> >> >> drreta@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 <
>>> >> >> >>>>>>> drreta@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.20201226124316@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

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

 I accidentally clicked the send button, please ignore my previous email
and look at this reply.

On Sat, Jan 29, 2022 at 7:58 PM Jim Ma <ma...@gmail.com> wrote:

>
>
>
> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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.
>
>
>
  From the JakartaEE9 release[1]and JakartaEE10 plan[2], it still needs to
support JDK11. Jakarta Restful WebService 3.0/3.1  and Jakarta XML Web
Services 3.0/3.1
  apis are the specifications we need to implement in CXF, so we need to
build, run and test implementation with JDK11.

  Just thinking this loud, is it possible that we make Spring plugable or
really optional ?  4.x is the major release and it's the chance
  to refactor CXF code(like we move spring related source/test to separate
module) to build/run/test without Spring with a maven profile.

 [1]
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
 [2]
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 <dr...@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 <dr...@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 <
>> >> >> rmannibucau@gmail.com>
>> >> >> JM> wrote:
>>
>>
>>
>>
>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
>> écrit
>> >> :
>>
>>
>>
>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >> >> rmannibucau@gmail.com>
>> >> >> >>> wrote:
>>
>>
>>
>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com> a
>> >> écrit :
>>
>>
>>
>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> >> >> >>>>> rmannibucau@gmail.com> wrote:
>>
>>
>>
>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <dr...@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 <rm...@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 <
>> >> drreta@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 <
>> >> >> drreta@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 <
>> >> >> >>>>>>> drreta@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.20201226124316@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
>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma <ma...@gmail.com>]

On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <dr...@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.


  From the JakartaEE10 release plan[1], it still needs to support JDK11.
Jakarta Restful Webservice 3.1 and Jakarta XML Web Services 4.0.

  Just thinking this loud, is it possible that we make Spring plugable  ?
In

  [1]
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 <dr...@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 <dr...@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 <
> >> >> rmannibucau@gmail.com>
> >> >> JM> wrote:
>
>
>
>
> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <ma...@gmail.com> a
> écrit
> >> :
>
>
>
> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
> >> >> rmannibucau@gmail.com>
> >> >> >>> wrote:
>
>
>
> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <ma...@gmail.com> a
> >> écrit :
>
>
>
> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
> >> >> >>>>> rmannibucau@gmail.com> wrote:
>
>
>
> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <dr...@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 <rm...@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 <
> >> drreta@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 <
> >> >> drreta@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 <
> >> >> >>>>>>> drreta@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.20201226124316@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
>
>