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