+1 I would suggest to deal with this in documentation, restricting runtime jdk support to JDK17+ is actually going to create problems to some integration (Spring is effectively optional already), while not really giving us much (if you know you use Spring, just use JDK17, no need for it to be mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or 11; support for JDK 17 is something coming with JakartaEE 10 afair.
Thanks On Tue, Nov 8, 2022 at 1:34 PM Jim Ma <mail2ji...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > -- Alessio Soldano Manager, Software Engineering Red Hat <https://www.redhat.com> <https://www.redhat.com>
