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
