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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]/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 <[email protected]> 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 <[email protected]> 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 > >
