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 <drr...@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 <mail2ji...@gmail.com> wrote:
>> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy Redko <drr...@gmail.com> wrote:
>> >>> Hey guys,
>> >>> A bunch of good things have happened at the end of this year. The 3.5.0
>> >>> out and we are in a good
>> >>> shape to kick off Jakarta support: the Spring 6 milestones and Spring
>> >>> Boot 3 snapshots are already
>> >>> available. There are tons of things to fix and address, I have created
>> >>> this draft pull request [1]
>> >>> with a first batch of changes and TODOs. Everyone should be able to
>> push
>> >>> changes in there, if not
>> >>> - please let me know, I could give perms / move the branch to CXF
>> Github
>> >>> repo. Hope in the next
>> >>> couple of months we get closer to fully embrace Jakarta.
>> >>> On the not so good news side, Spring 6 has kept JDK-17 baseline. It
>> does
>> >>> not play well with our
>> >>> original plan to stick to JDK-11 baseline for 4.x but I am not sure we
>> >>> have any choice here besides
>> >>> bumping the baseline as well.
>> JM> From the JakartaEE9 release[1]and JakartaEE10 plan[2], it still
>> needs to
>> JM> support JDK11. Jakarta Restful WebService 3.0/3.1 and Jakarta XML Web
>> JM> Services 3.0/3.1
>> JM> apis are the specifications we need to implement in CXF, so we need
>> to
>> JM> build, run and test implementation with JDK11.
>> JM> Just thinking this loud, is it possible that we make Spring plugable
>> or
>> JM> really optional ? 4.x is the major release and it's the chance
>> JM> to refactor CXF code(like we move spring related source/test to
>> separate
>> JM> module) to build/run/test without Spring with a maven profile.
>> JM> [1]
>> JM>
>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
>> JM> [2]
>> JM>
>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan
>> >>> Happy Holidays guys!
>> >>> [1] https://github.com/apache/cxf/pull/888
>> >>> JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy Redko <drr...@gmail.com>
>> wrote:
>> >>> >> Hey Jim,
>> >>> >> No, we don't have a branch just yet, primarily because we depend on
>> the
>> >>> >> few
>> >>> >> snapshots in 3.5.0/master.
>> >>> >> @Colm do you have an idea regarding xmlschema 2.3.0 release
>> timelines?
>> >>> >> @Dan do you have an idea regarding neethi 3.2.0 release timelines?
>> >>> >> At worst, you could create a new branch for this feature, or submit
>> a
>> >>> >> pull request against master which we should be able to re-target
>> later
>> >>> >> against the right branch (should be easy). What do you think?
>> >>> JM> This is a good idea. I'll send a PR against the master, and later
>> we
>> >>> can
>> >>> JM> decide the place to merge.
>> >>> JM> Thanks, Andriy.
>> >>> >> Best Regards,
>> >>> >> Andriy Redko
>> >>> >> JM> Thanks for more updates , Andriy.
>> >>> >> JM> Is there a place/workspace branch, I can send a PR for this
>> >>> change?
>> >>> >> JM> On Fri, Sep 3, 2021 at 9:20 PM Andriy Redko <drr...@gmail.com>
>> >>> wrote:
>> >>> >> >> Hey Jim,
>> >>> >> >> Thanks a lot for taking the lead on this one. Just want to chime
>> in
>> >>> on a
>> >>> >> >> few points. Indeed, as
>> >>> >> >> per previous discussion in this thread, it seems like it make
>> sense
>> >>> to
>> >>> >> >> provide only the subset
>> >>> >> >> of shaded modules with Jakarta namespace. Also, it was confirmed
>> >>> >> yesterday
>> >>> >> >> that Spring Framework
>> >>> >> >> 6 milestones will be available in November this year but the
>> first
>> >>> >> >> snapshots will be out in late
>> >>> >> >> September / early October, looks pretty promising. One
>> >>> **unexpected**
>> >>> >> part
>> >>> >> >> of the announcement
>> >>> >> >> is JDK17 baseline for Spring Framework & Co, that could be a
>> bummer
>> >>> but
>> >>> >> I
>> >>> >> >> have the feeling that
>> >>> >> >> it will be lowered to JDK11. Thank you.
>> >>> >> >> Best Regards,
>> >>> >> >> Andriy Redko
>> >>> >> >> JM> Good point, Romain. We need to look at what to do to make
>> sure
>> >>> all
>> >>> >> >> JM> artifacts are included and transformed if this becomes a cxf
>> >>> module.
>> >>> >> >> JM> BTW, Spring 6 GA supports jakarta ee9 will come in Q4 2022 :
>> >>> >> >> JM>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>> >>> >> >> JM> On Fri, Sep 3, 2021 at 6:20 PM Romain Manni-Bucau <
>> >>> >> >> rmannibu...@gmail.com>
>> >>> >> >> JM> wrote:
>> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim Ma <mail2ji...@gmail.com> a
>> >>> écrit
>> >>> >> :
>> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau <
>> >>> >> >> rmannibu...@gmail.com>
>> >>> >> >> >>> wrote:
>> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, Jim Ma <mail2ji...@gmail.com>
>> a
>> >>> >> écrit :
>> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>> >>> >> >> >>>>> rmannibu...@gmail.com> wrote:
>> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko <
>> drr...@gmail.com>
>> >>> a
>> >>> >> >> >>>>>> écrit :
>> >>> >> >> >>>>>>> Hi Romain,
>> >>> >> >> >>>>>>> Sorry for the delayed response. I have been thinking
>> about
>> >>> your
>> >>> >> >> (and
>> >>> >> >> >>>>>>> Jim) suggestions
>> >>> >> >> >>>>>>> and came to surprising conclusion: do we actually need to
>> >>> >> >> officially
>> >>> >> >> >>>>>>> release anything
>> >>> >> >> >>>>>>> to shade/overwrite javax <-> jakarta? Generally, we could
>> >>> shade
>> >>> >> >> >>>>>>> Spring or/and any other
>> >>> >> >> >>>>>>> dependency but we would certainly not bundle it as part
>> of
>> >>> CXF
>> >>> >> >> >>>>>>> distribution (I hope you
>> >>> >> >> >>>>>>> would agree), so not really useful unless we publish
>> them.
>> >>> As
>> >>> >> such,
>> >>> >> >> >>>>>>> probably the best
>> >>> >> >> >>>>>>> interim solution is to document what it takes to shade
>> CXF
>> >>> >> (javax
>> >>> >> >> <->
>> >>> >> >> >>>>>>> jakarta) and let
>> >>> >> >> >>>>>>> the end users (application/service developers) use that
>> when
>> >>> >> >> needed?
>> >>> >> >> >>>>>>> In this case
>> >>> >> >> >>>>>>> basically CXF, Spring, Geronimo, Swagger, ... would
>> follow
>> >>> the
>> >>> >> same
>> >>> >> >> >>>>>>> shading rules. At
>> >>> >> >> >>>>>>> least, we could start with that (documenting the shading
>> >>> >> process)
>> >>> >> >> and
>> >>> >> >> >>>>>>> likely get some
>> >>> >> >> >>>>>>> early feedback while working on full-fledged support?
>> WDYT?
>> >>> >> >> >>>>>> This is what is done and makes it hard for nothing to
>> >>> >> maintain/fix -
>> >>> >> >> >>>>>> dont even look at tomee solution for shading please ;) -
>> >>> IMHO.
>> >>> >> >> >>>>>> Being said it costs nothing to cxf to produce jakarta
>> jars,
>> >>> that
>> >>> >> it
>> >>> >> >> >>>>>> makes it ee 9 compliant and more consistent for all but
>> >>> spring
>> >>> >> >> usage (ee
>> >>> >> >> >>>>>> integrators, plain tomcat 10 users etc...), I think it is
>> >>> worth
>> >>> >> >> doing it,
>> >>> >> >> >>>>>> at minimum.
>> >>> >> >> >>>>>> At least a jakarta jaxrs (over jakarta servlet) bundle
>> would
>> >>> be a
>> >>> >> >> good
>> >>> >> >> >>>>>> progress, not sure jaxws and other parts would be helpful
>> >>> since
>> >>> >> >> they tend
>> >>> >> >> >>>>>> to be in maintainance mode from what I saw.
>> >>> >> >> >>>>>> So IMHO the best is a shade/relocation in the parent to
>> >>> deliver a
>> >>> >> >> >>>>>> jakarta artifact for all module + a few jakarta bom. But
>> if
>> >>> too
>> >>> >> >> much -
>> >>> >> >> >>>>>> which I can see/hear - a jakarta jaxrs bundle would work
>> too
>> >>> >> short
>> >>> >> >> term.
>> >>> >> >> >>>>> I agree to start with something to preview and collect more
>> >>> ideas
>> >>> >> to
>> >>> >> >> >>>>> support ee9. It's good to have a branch to really start
>> >>> something
>> >>> >> >> for this
>> >>> >> >> >>>>> topic.
>> >>> >> >> >>>>> @Romain, do you have a prototype with shading or other
>> tools
>> >>> for a
>> >>> >> >> >>>>> jakarta jaxrs bundle or just some basic idea that we can
>> have
>> >>> a
>> >>> >> look
>> >>> >> >> at ?
>> >>> >> >> >>>> Not ready for cxf but looking at meecrowave-core pom you
>> would
>> >>> have
>> >>> >> >> some
>> >>> >> >> >>>> idea.
>> >>> >> >> >>>> I just suspect pom deps need some refinement like
>> with/without
>> >>> the
>> >>> >> >> >>>> client (it is useless with java 11 now and less and less
>> >>> desired
>> >>> >> >> AFAIK).
>> >>> >> >> >>> @Romain Manni-Bucau <rmannibu...@gmail.com> Thanks for the
>> >>> >> update. I
>> >>> >> >> >>> looked at the meecrowave-core pom and understood how it
>> >>> transforms
>> >>> >> >> package
>> >>> >> >> >>> names with the shade plugin. Both shade plugin or eclipse
>> >>> >> transformer
>> >>> >> >> tool
>> >>> >> >> >>> works for this purpose .
>> >>> >> >> >>> I created one prototype project which pulls in cxf
>> dependencies,
>> >>> >> >> >>> transforms to jakarta namespace and installs to local maven
>> >>> >> >> repository :
>> >>> >> >> >>> https://github.com/jimma/cxf-ee9-transformer
>> >>> >> >> >>> This doesn't need more effort and no need the code/dependency
>> >>> change
>> >>> >> >> >>> which breaks/mixes with javax support codebase. It can be
>> simply
>> >>> >> added
>> >>> >> >> with
>> >>> >> >> >>> another maven module in cxf repo to produce transformed
>> jakata
>> >>> cxf
>> >>> >> >> >>> artifacts or binary distribution. Your thoughts ?
>> >>> >> >> >> If not all artifacts are proposed with jakarta support it is
>> an
>> >>> >> option
>> >>> >> >> >> otherwise it would need a build module to synchronize this
>> >>> >> submodule(s)
>> >>> >> >> to
>> >>> >> >> >> ensure none are forgotten - this is where I prefer the
>> classifier
>> >>> >> >> approach
>> >>> >> >> >> even if it has this exclusion pitfalls - but cxf has it anyway
>> >>> due to
>> >>> >> >> its
>> >>> >> >> >> transitive dependencies so not worse IMHO ;).
>> >>> >> >> >>>>> Thanks,
>> >>> >> >> >>>>> Jim
>> >>> >> >> >>>>>>> Thank you.
>> >>> >> >> >>>>>>> Best Regards,
>> >>> >> >> >>>>>>> Andriy Redko
>> >>> >> >> >>>>>>> RMB> I'm not sure I see why you need spring to start this
>> >>> work.
>> >>> >> The
>> >>> >> >> >>>>>>> expected is
>> >>> >> >> >>>>>>> RMB> there already so spring module can still rely on
>> >>> javax, be
>> >>> >> >> made
>> >>> >> >> >>>>>>> jakarta
>> >>> >> >> >>>>>>> RMB> friendly using shade plugin or alike and that's it
>> >>> until a
>> >>> >> >> >>>>>>> spring native
>> >>> >> >> >>>>>>> RMB> integration is there.
>> >>> >> >> >>>>>>> RMB> Worse case cxf-spring will not be usable with
>> jakarta -
>> >>> >> which
>> >>> >> >> >>>>>>> still enabled
>> >>> >> >> >>>>>>> RMB> all other usages, best case if spring makes the
>> >>> transition
>> >>> >> >> >>>>>>> smooth is that
>> >>> >> >> >>>>>>> RMB> it will work smoothly without more investment than
>> for
>> >>> the
>> >>> >> >> rest
>> >>> >> >> >>>>>>> of the
>> >>> >> >> >>>>>>> RMB> build.
>> >>> >> >> >>>>>>> RMB> The pro of that options is that it will reduce the
>> >>> number
>> >>> >> of
>> >>> >> >> >>>>>>> unofficial cxf
>> >>> >> >> >>>>>>> RMB> relocations sooner IMHO.
>> >>> >> >> >>>>>>> RMB> Romain Manni-Bucau
>> >>> >> >> >>>>>>> RMB> @rmannibucau <https://twitter.com/rmannibucau> |
>> Blog
>> >>> >> >> >>>>>>> RMB> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>> >> >> >>>>>>> RMB> <http://rmannibucau.wordpress.com> | Github <
>> >>> >> >> >>>>>>> https://github.com/rmannibucau> |
>> >>> >> >> >>>>>>> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>> |
>> >>> Book
>> >>> >> >> >>>>>>> RMB> <
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >>> >> >> >>>>>>> >
>> >>> >> >> >>>>>>> RMB> Le lun. 16 août 2021 à 23:40, Andriy Redko <
>> >>> >> drr...@gmail.com>
>> >>> >> >> a
>> >>> >> >> >>>>>>> écrit :
>> >>> >> >> >>>>>>> >> Hi Jim,
>> >>> >> >> >>>>>>> >> I will try to answer your questions, other guys will
>> >>> >> definitely
>> >>> >> >> >>>>>>> share more
>> >>> >> >> >>>>>>> >> thoughts, please see mine inlined.
>> >>> >> >> >>>>>>> >> >> What's the task for JDK-17 LTS preparation ? Do we
>> >>> need
>> >>> >> to
>> >>> >> >> >>>>>>> support
>> >>> >> >> >>>>>>> >> build 3.5.0 with JDK-17 ?
>> >>> >> >> >>>>>>> >> Build + All tests are green.
>> >>> >> >> >>>>>>> >> Apache Karaf 4.3.3 will support JDK17 so our OSGi test
>> >>> suites
>> >>> >> >> will
>> >>> >> >> >>>>>>> pass.
>> >>> >> >> >>>>>>> >> Besides that, there is still some work to do [1] but
>> at
>> >>> >> least we
>> >>> >> >> >>>>>>> have
>> >>> >> >> >>>>>>> >> workarounds.
>> >>> >> >> >>>>>>> >> >> For Jakarta ee9 support branch 4.x with source code
>> >>> >> change to
>> >>> >> >> >>>>>>> support
>> >>> >> >> >>>>>>> >> jakarta namespace , we have to wait for spring and
>> other
>> >>> >> >> >>>>>>> >> >> third party dependencies jakarta ee9 ready. Now we
>> >>> don't
>> >>> >> >> know
>> >>> >> >> >>>>>>> when
>> >>> >> >> >>>>>>> >> these dependencies are all ready and we can start this
>> >>> work.
>> >>> >> >> >>>>>>> >> This is correct, the earliest we could expect
>> something
>> >>> is
>> >>> >> >> Q4/2021
>> >>> >> >> >>>>>>> (fe
>> >>> >> >> >>>>>>> >> Spring).
>> >>> >> >> >>>>>>> >> >> Given there is no features added in Jakarta ee 9.1
>> >>> besides
>> >>> >> >> the
>> >>> >> >> >>>>>>> >> namespace change, we can provide the jakarta calssfier
>> >>> maven
>> >>> >> >> >>>>>>> artifacts
>> >>> >> >> >>>>>>> >> >> and binary release in 3.6.x or 4.x with
>> >>> transformation or
>> >>> >> >> other
>> >>> >> >> >>>>>>> better
>> >>> >> >> >>>>>>> >> approach will be enough.We provide jakarta ee9 support
>> >>> early,
>> >>> >> >> >>>>>>> >> >> then we can get more feedback on this topic.
>> >>> >> >> >>>>>>> >> It is definitely the option we have among others to
>> >>> discuss.
>> >>> >> I
>> >>> >> >> >>>>>>> have no
>> >>> >> >> >>>>>>> >> doubts that everyone has rough idea of the pros and
>> cons
>> >>> >> >> >>>>>>> >> each option has, as the team we are trying to pick the
>> >>> best
>> >>> >> path
>> >>> >> >> >>>>>>> forward.
>> >>> >> >> >>>>>>> >> Jakarta EE 10 is coming in Q1/2022 [2], we should
>> keep it
>> >>> >> >> >>>>>>> >> in mind as well.
>> >>> >> >> >>>>>>> >> Thank you!
>> >>> >> >> >>>>>>> >> [1] https://issues.apache.org/jira/browse/CXF-8407
>> >>> >> >> >>>>>>> >> [2]
>> >>> >> >> >>>>>>> >>
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan
>> >>> >> >> >>>>>>> >> Best Regards,
>> >>> >> >> >>>>>>> >> Andriy Redko
>> >>> >> >> >>>>>>> >> JM> On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko <
>> >>> >> >> drr...@gmail.com>
>> >>> >> >> >>>>>>> wrote:
>> >>> >> >> >>>>>>> >> >> Hey Jim, Romain,
>> >>> >> >> >>>>>>> >> >> Thank you guys, I think Romain's suggestion to move
>> >>> 3.5.x
>> >>> >> to
>> >>> >> >> >>>>>>> JDK-11
>> >>> >> >> >>>>>>> >> >> baseline is good idea, we would
>> >>> >> >> >>>>>>> >> >> still be maintaining 3.4.x for a while, covering
>> JDK-8
>> >>> >> based
>> >>> >> >> >>>>>>> >> deployments.
>> >>> >> >> >>>>>>> >> >> Regarding Jakarta, yes, I
>> >>> >> >> >>>>>>> >> >> certainly remember the discussion regarding the
>> build
>> >>> time
>> >>> >> >> >>>>>>> approach,
>> >>> >> >> >>>>>>> >> >> personally with time I came to the
>> >>> >> >> >>>>>>> >> >> conclusion that this is not the best option for at
>> >>> least 2
>> >>> >> >> >>>>>>> reasons:
>> >>> >> >> >>>>>>> >> >> - differences between source vs binary artifacts
>> are
>> >>> very
>> >>> >> >> >>>>>>> confusing
>> >>> >> >> >>>>>>> >> >> (source imports javax,
>> >>> >> >> >>>>>>> >> >> binary has jakarta, or vice versa), I think we
>> all
>> >>> run
>> >>> >> >> into
>> >>> >> >> >>>>>>> that from
>> >>> >> >> >>>>>>> >> >> time to time
>> >>> >> >> >>>>>>> >> >> - Jakarta is the way to go, the mainstream should
>> >>> have
>> >>> >> first
>> >>> >> >> >>>>>>> class
>> >>> >> >> >>>>>>> >> support
>> >>> >> >> >>>>>>> >> >> Just my 5 cents, but we certainly should consider
>> this
>> >>> >> >> approach
>> >>> >> >> >>>>>>> as well,
>> >>> >> >> >>>>>>> >> >> there are good points to
>> >>> >> >> >>>>>>> >> >> follow it, summarizing what we have at the moment:
>> >>> >> >> >>>>>>> >> >> Option #1:
>> >>> >> >> >>>>>>> >> >> - release 3.5.0 in preparation to JDK-17 LTS,
>> keeping
>> >>> >> JDK-8
>> >>> >> >> as
>> >>> >> >> >>>>>>> baseline
>> >>> >> >> >>>>>>> >> >> - move master to 3.6.x (4.x?) with JDK-11 as the
>> >>> minimal
>> >>> >> >> >>>>>>> required JDK
>> >>> >> >> >>>>>>> >> >> version (Jetty 10, ...)
>> >>> >> >> >>>>>>> >> >> - branch off 5.x (4.x?) to continue the work on
>> >>> >> supporting
>> >>> >> >> >>>>>>> Jakarta
>> >>> >> >> >>>>>>> >> 9.0+,
>> >>> >> >> >>>>>>> >> >> with JDK-11 as the minimal
>> >>> >> >> >>>>>>> >> >> required JDK version (Jetty 11, ...)
>> >>> >> >> >>>>>>> >> JM> What's the task for JDK-17 LTS preparation ? Do
>> we
>> >>> need
>> >>> >> to
>> >>> >> >> >>>>>>> support
>> >>> >> >> >>>>>>> >> build
>> >>> >> >> >>>>>>> >> JM> 3.5.0 with JDK-17 ?
>> >>> >> >> >>>>>>> >> JM> For Jakarta ee9 support branch 4.x with source
>> code
>> >>> >> change
>> >>> >> >> to
>> >>> >> >> >>>>>>> support
>> >>> >> >> >>>>>>> >> JM> jakarta namespace , we have to wait for spring and
>> >>> other
>> >>> >> >> >>>>>>> >> JM> third party dependencies jakarta ee9 ready. Now
>> we
>> >>> don't
>> >>> >> >> know
>> >>> >> >> >>>>>>> when
>> >>> >> >> >>>>>>> >> these
>> >>> >> >> >>>>>>> >> JM> dependencies are all ready and we can start this
>> >>> work.
>> >>> >> >> >>>>>>> >> JM> Given there is no features added in Jakarta ee 9.1
>> >>> >> besides
>> >>> >> >> the
>> >>> >> >> >>>>>>> >> namespace
>> >>> >> >> >>>>>>> >> JM> change, we can provide the jakarta calssfier maven
>> >>> >> artifacts
>> >>> >> >> >>>>>>> and binary
>> >>> >> >> >>>>>>> >> JM> release in 3.6.x or 4.x with transformation or
>> other
>> >>> >> better
>> >>> >> >> >>>>>>> approach
>> >>> >> >> >>>>>>> >> will
>> >>> >> >> >>>>>>> >> JM> be enough.We provide jakarta ee9 support early,
>> then
>> >>> we
>> >>> >> can
>> >>> >> >> >>>>>>> get more
>> >>> >> >> >>>>>>> >> JM> feedback on this topic.
>> >>> >> >> >>>>>>> >> >> Option #2:
>> >>> >> >> >>>>>>> >> >> - release 3.5.0 in preparation to JDK-17 LTS, use
>> >>> JDK-11
>> >>> >> as
>> >>> >> >> >>>>>>> baseline
>> >>> >> >> >>>>>>> >> >> - handle javax by a build setup (with api
>> validation
>> >>> at
>> >>> >> >> build
>> >>> >> >> >>>>>>> time to
>> >>> >> >> >>>>>>> >> >> avoid regressions) and use jakarta package as main
>> >>> api in
>> >>> >> the
>> >>> >> >> >>>>>>> project
>> >>> >> >> >>>>>>> >> >> (Romain), or
>> >>> >> >> >>>>>>> >> >> adding a new maven module to transform cxf
>> >>> artifacts
>> >>> >> with
>> >>> >> >> >>>>>>> jakarta
>> >>> >> >> >>>>>>> >> >> package name (Jim)
>> >>> >> >> >>>>>>> >> >> Option #3:
>> >>> >> >> >>>>>>> >> >> - release 3.5.0 in preparation to JDK-17 LTS, use
>> >>> JDK-11
>> >>> >> as
>> >>> >> >> >>>>>>> baseline
>> >>> >> >> >>>>>>> >> >> - move master to 4.x to continue the work on
>> >>> supporting
>> >>> >> >> >>>>>>> Jakarta 9.0+,
>> >>> >> >> >>>>>>> >> >> with JDK-11 as the minimal
>> >>> >> >> >>>>>>> >> >> required JDK version (Jetty 11, ...)
>> >>> >> >> >>>>>>> >> >> Thank you!
>> >>> >> >> >>>>>>> >> >> Best Regards,
>> >>> >> >> >>>>>>> >> >> Andriy Redko
>> >>> >> >> >>>>>>> >> >> JM> On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko <
>> >>> >> >> >>>>>>> drr...@gmail.com>
>> >>> >> >> >>>>>>> >> >> wrote:
>> >>> >> >> >>>>>>> >> >> >> Hey guys,
>> >>> >> >> >>>>>>> >> >> >> I would like to initiate (or better to say,
>> >>> resume) the
>> >>> >> >> >>>>>>> discussion
>> >>> >> >> >>>>>>> >> >> >> regarding CXF 3.5.x and beyond.
>> >>> >> >> >>>>>>> >> >> >> The 3.5.x has been in the making for quite a
>> >>> while but
>> >>> >> >> has
>> >>> >> >> >>>>>>> not seen
>> >>> >> >> >>>>>>> >> any
>> >>> >> >> >>>>>>> >> >> >> releases yet. As far as
>> >>> >> >> >>>>>>> >> >> >> I know, we have only pending upgrade to Apache
>> >>> Karaf
>> >>> >> 4.3.3
>> >>> >> >> >>>>>>> (on
>> >>> >> >> >>>>>>> >> SNAPSHOT
>> >>> >> >> >>>>>>> >> >> >> now) so be ready to meet
>> >>> >> >> >>>>>>> >> >> >> JDK 17 LTS next month. I think this is a good
>> >>> >> opportunity
>> >>> >> >> to
>> >>> >> >> >>>>>>> release
>> >>> >> >> >>>>>>> >> >> 3.5.0
>> >>> >> >> >>>>>>> >> >> >> but certainly looking
>> >>> >> >> >>>>>>> >> >> >> for ideas and opinions here. Importantly, I
>> think
>> >>> for
>> >>> >> >> 3.5.x
>> >>> >> >> >>>>>>> the JDK-8
>> >>> >> >> >>>>>>> >> >> >> should be supported as the minimal
>> >>> >> >> >>>>>>> >> >> >> required JDK version (just an opinion since
>> JDK-8
>> >>> is
>> >>> >> still
>> >>> >> >> >>>>>>> very
>> >>> >> >> >>>>>>> >> widely
>> >>> >> >> >>>>>>> >> >> >> used).
>> >>> >> >> >>>>>>> >> >> >> On the other side, many libraries (Jetty, wss4j,
>> >>> ...)
>> >>> >> are
>> >>> >> >> >>>>>>> bumping the
>> >>> >> >> >>>>>>> >> >> >> baseline to JDK-11. The work
>> >>> >> >> >>>>>>> >> >> >> @Colm is doing to update to OpenSaml 4.x [1] is
>> a
>> >>> good
>> >>> >> >> >>>>>>> argument to
>> >>> >> >> >>>>>>> >> have
>> >>> >> >> >>>>>>> >> >> >> the JDK-11+ release line. Should
>> >>> >> >> >>>>>>> >> >> >> we have a dedicated 3.6.x or 4.x.x branch(es)
>> for
>> >>> that?
>> >>> >> >> >>>>>>> >> >> >> Last but not least, Jakarta 9.0+ support. Last
>> >>> year we
>> >>> >> >> >>>>>>> briefly talked
>> >>> >> >> >>>>>>> >> >> >> about it [2], at this moment it
>> >>> >> >> >>>>>>> >> >> >> looks like having dedicated release line
>> (4.x/5.x)
>> >>> with
>> >>> >> >> >>>>>>> Jakarta
>> >>> >> >> >>>>>>> >> >> artifacts
>> >>> >> >> >>>>>>> >> >> >> is beneficial in long term.
>> >>> >> >> >>>>>>> >> >> >> Large chunk [3] of work has been already done in
>> >>> this
>> >>> >> >> >>>>>>> direction. The
>> >>> >> >> >>>>>>> >> >> >> Spring 6 milestones with Jakarta
>> >>> >> >> >>>>>>> >> >> >> support are expected to land in Q4/2021 [4] but
>> I
>> >>> am
>> >>> >> not
>> >>> >> >> >>>>>>> sure what
>> >>> >> >> >>>>>>> >> plans
>> >>> >> >> >>>>>>> >> >> >> Apache Karaf team has, @Freeman
>> >>> >> >> >>>>>>> >> >> >> do you have any insights?
>> >>> >> >> >>>>>>> >> >> JM> For Jakarta EE9 support , the another option
>> >>> could be
>> >>> >> >> >>>>>>> adding a new
>> >>> >> >> >>>>>>> >> >> maven
>> >>> >> >> >>>>>>> >> >> JM> module to transform cxf artifacts
>> >>> >> >> >>>>>>> >> >> JM> with jakarta package name. This transformed
>> >>> artifact
>> >>> >> can
>> >>> >> >> >>>>>>> coexist
>> >>> >> >> >>>>>>> >> with
>> >>> >> >> >>>>>>> >> >> the
>> >>> >> >> >>>>>>> >> >> JM> javax namespace with "jakarta" classifier,
>> >>> >> >> >>>>>>> >> >> JM> and we don't have to maintain two branches
>> until
>> >>> >> Jakarta
>> >>> >> >> >>>>>>> EE10 and
>> >>> >> >> >>>>>>> >> >> there are
>> >>> >> >> >>>>>>> >> >> JM> new features added.
>> >>> >> >> >>>>>>> >> >> JM> Other projects like hibernate and jackson use
>> this
>> >>> >> shade
>> >>> >> >> >>>>>>> plugin or
>> >>> >> >> >>>>>>> >> >> Eclipse
>> >>> >> >> >>>>>>> >> >> JM> transformer to support jakarta ee9:
>> >>> >> >> >>>>>>> >> >> JM>
>> >>> >> >> >>>>>>> >> >>
>> >>> >> >> >>>>>>> >>
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100
>> >>> >> >> >>>>>>> >> >> JM>
>> >>> >> >> >>>>>>> >> >>
>> >>> >> >> >>>>>>> >>
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.xml#L115
>> >>> >> >> >>>>>>> >> >> >> To summarize briefly:
>> >>> >> >> >>>>>>> >> >> >> - release 3.5.0 in preparation to JDK-17 LTS,
>> >>> keeping
>> >>> >> >> JDK-8
>> >>> >> >> >>>>>>> as
>> >>> >> >> >>>>>>> >> baseline
>> >>> >> >> >>>>>>> >> >> >> - move master to 3.6.x (4.x?) with JDK-11 as
>> the
>> >>> >> minimal
>> >>> >> >> >>>>>>> required
>> >>> >> >> >>>>>>> >> JDK
>> >>> >> >> >>>>>>> >> >> >> version (Jetty 10, ...)
>> >>> >> >> >>>>>>> >> >> >> - branch off 5.x (4.x?) to continue the work on
>> >>> >> >> supporting
>> >>> >> >> >>>>>>> Jakarta
>> >>> >> >> >>>>>>> >> >> 9.0+,
>> >>> >> >> >>>>>>> >> >> >> with JDK-11 as the minimal
>> >>> >> >> >>>>>>> >> >> >> required JDK version (Jetty 11, ...)
>> >>> >> >> >>>>>>> >> >> >> I think it is very clear that maintaining
>> JavaEE +
>> >>> >> JDK8 /
>> >>> >> >> >>>>>>> JavaEE +
>> >>> >> >> >>>>>>> >> >> JDK11 /
>> >>> >> >> >>>>>>> >> >> >> Jakarta + JDK11 would consume
>> >>> >> >> >>>>>>> >> >> >> much more time from the team, but I am not sure
>> we
>> >>> have
>> >>> >> >> other
>> >>> >> >> >>>>>>> >> options if
>> >>> >> >> >>>>>>> >> >> >> we aim to evolve and keep CXF
>> >>> >> >> >>>>>>> >> >> >> up to date. Any thought, ideas, comments,
>> >>> suggestions
>> >>> >> >> guys?
>> >>> >> >> >>>>>>> >> >> >> Thank you!
>> >>> >> >> >>>>>>> >> >> >> [1]
>> https://github.com/apache/cxf/tree/opensaml4
>> >>> >> >> >>>>>>> >> >> >> [2]
>> >>> >> >> >>>>>>> >> >> >>
>> >>> >> >> >>>>>>> >> >>
>> >>> >> >> >>>>>>> >>
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> http://mail-archives.apache.org/mod_mbox/cxf-dev/202012.mbox/%3c1503263798.20201226124...@gmail.com%3E
>> >>> >> >> >>>>>>> >> >> >> [3] https://github.com/apache/cxf/pull/737
>> >>> >> >> >>>>>>> >> >> >> [4]
>> >>> >> >> >>>>>>> >> >> >>
>> >>> >> >> >>>>>>> >> >>
>> >>> >> >> >>>>>>> >>
>> >>> >> >> >>>>>>>
>> >>> >> >>
>> >>> >>
>> >>>
>> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
>> >>> >> >> >>>>>>> >> >> >> Best Regards,
>> >>> >> >> >>>>>>> >> >> >> Andriy Redko
