Yes. Spring is optional for CXF runtime for a long time.  Now all CXF
binary classes/artifacts are all JDK-11 version (class major version
55) as Andriy
mentioned
we set target/source to JDK-11.  I believe this setting on CXF at the
moment is the best option:

   - Users don't need to upgrade the JDK version if they are using CXF
   without Spring. FWIK, there are a lot of  non-Spring CXF users out there.
   - For the CXF Spring users, because the Spring 6 Jakarta version is
   JDK-17 baseline and built classes are JDK-17 versions(class major version
   61),  they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
   mandatory from Spring 6 and not from CXF.


On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <freeman.f...@gmail.com> wrote:

> Hello,
>
> FWIW,  Spring isn't mandatory for CXF, cxf-core only depends on spring
> optionally and we don't need to have spring artifacts on the classpath if
> we don't want to use spring/spring boot features, and this has been the
> case for a very long time.
>
> Freeman
>
> On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > I was more referencing the long awaited split of cxf-core (it is still
> the
> > same old content than for the early jaxws time and without a modular
> design
> > - this is where spring comes from mainly IIRC) so for a 4.0.0 this sounds
> > like a big awaited features (don't start by bringing 1.4M said
> otherwise).
> > Since several part of OSGi dropped I think it would be good to create
> > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > Since next release is mainly enabling cxf to hit jakarta, it sounds fine
> > for me to drop spring if the refactor is too much and would delay a lot
> the
> > release - agree on this one.
> > But keeping it like that means it will stay for years so likely that cxf
> 4
> > will be the same than cxf 3 on this point which would be sad IMHO.
> >
> > Side note: indeed the obvious answer to that point is "v5" but it is
> > pushing again this issue (coming from v2 ;)) and also makes the
> versioning
> > harder to follow if not pushed too far IMHO.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <drr...@gmail.com> a écrit :
> >
> > > Hi Romain,
> > >
> > > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > > Spring
> > > (this is basically another "few months long" effort), it is merely to
> try
> > > to
> > > not bring any dependency with JDK-17 baseline (== Spring / Spring Boot
> at
> > > this moment) by default. It would definitely require more work for the
> > > users
> > > to wire everything properly but at least that would allow us to
> preserve
> > > JDK-11
> > > baseline. Apologies if I am rephrasing what you intended to say, just
> an
> > > attempt to eliminate the possible confusion.
> > >
> > > Thank you.
> > >
> > >
> > > > Think Java 11 is a good baseline as of today - at least to enable
> > Jakarta
> > > > vendors to use CXF as an implementation and pass tck.
> > > > +1 to drop spring if it bothers to get a first 4.0.0 release out, we
> > can
> > > > catch up later like other dropped integrations and core should be
> > > exploded
> > > > anyway, it is way too fat for what it does so moving spring out of it
> > is
> > > > quite a good direction IMHO.
> > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <freeman.f...@gmail.com> a
> > > écrit :
> > >
> > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > since we
> > > >> upgraded to Spring 6 and Spring Boot 3.
> > >
> > > >> Thanks to all guys involved in this long process!
> > > >> Freeman
> > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <drr...@gmail.com>
> > wrote:
> > > >>> +1 to move forward with release (or milestone), but before that,
> > there
> > > is
> > > >>> one issue which
> > > >>> I would like to bring up and agree us upon. The initial discussion
> > for
> > > >>> Jakarta / 4.0.0 [1] concluded
> > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > misalignment
> > > >>> with Spring 6 / Spring Boot 3
> > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> > build
> > > >>> Jakarta / 4.0.0 branch (main) is
> > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > >
> > > >>> With that being said, the not so good part. Technically, Jakarta /
> > > 4.0.0
> > > >>> bits could be used in the
> > > >>> projects which are still using JDK-11. But because mostly every
> > single
> > > >>> piece (starting from cxf-core) depends
> > > >>> on Spring, the application fail to start with
> > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
> not
> > > >>> JDK-11 (we have hoped to isolate Spring
> > > >>> related implementation but it hasn't happened yet and not sure it
> > will
> > > in
> > > >>> the future). The question: does
> > > >>> anyone have a compelling usecase for keeping CXF baseline at JDK-11
> > > level
> > > >>> despite being able to run only
> > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > related
> > > >>> dependencies optional and document
> > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> used,
> > we
> > > >>> surely cannot leave things
> > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > > >>> baseline.
> > > >>> What do you guys think?
> > > >>> Thank you.
> > > >>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > >>> Best Regards,
> > > >>>     Andriy Redko
> > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > RMB>>>> +1 to release, there are too much forks out there already so
> > better
> > > >> to
> > > RMB>>>> release partially than not release at all 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. 7 nov. 2022 à 14:25, Misagh <misagh.moay...@gmail.com>
> a
> > > >>> écrit :
> > > >>>>> Hello all,
> > >
> > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a new
> > > >>>>> release of wss4j that would contain this change:
> > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > anticipated
> > > >>>>> to be GA before end of this year, hopefully.
> > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <mail2ji...@gmail.com>
> > wrote:
> > > >>>>>> Hi all,
> > > >>>>>> After 9 months of work, we finally fixed/worked around all
> issues
> > > >> for
> > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we
> > can
> > > >>> say
> > > >>>>> that
> > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> Jakarta
> > >
> > > >>>>> EE9.1).
> > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > community
> > > >>>>>> especially the user who asked for this jakarta artifacts like
> [1]
> > > >> and
> > > >>>>> get
> > > >>>>>> more feedback from our community, do you think it's time to
> > release
> > > >>> the
> > > >>>>> CXF
> > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > jakarta
> > >
> > > >>>>> release
> > > >>>>>> ?
> > > >>>>>> [1]
> > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > >>>>>> Thanks,
> > > >>>>>> Jim
> > >
> > >
> >
>

Reply via email to