Regarding cxf-core split, correct, we won't be able to make it in 4.0.0 but dependencies should be formalized as optional [1] so we won't bring them in unless Spring 6 / Spring Boot 3 is on the picture. Thanks!
[1] https://issues.apache.org/jira/browse/CXF-8791 Best Regards, Andriy Redko RMB> Hi, RMB> Ok so just to clarify it means RMB> 1. the cxf-core split (soap, rs, integration) is postponed > 4.x RMB> 2. the compiler setting is updated to add release (current setup is only RMB> source/target which does not guarantee that compiled with a jdk > version RMB> set in pom run on a lower jdk). 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 mar. 8 nov. 2022 à 13:25, Jim Ma <mail2ji...@gmail.com> a écrit : >> 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 >> > > > >> > > > >> > > >> > >>