You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jim Ma <ma...@gmail.com> on 2022/02/07 07:43:43 UTC
Re: [DISCUSS] CXF 3.5.x and beyond
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
Posted by 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