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