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