[GitHub] [cxf] jimma merged pull request #1023: [CXF-8789]:Configure release 11 to maven compiler plugin

[GitBox]

jimma merged PR #1023:
URL: https://github.com/apache/cxf/pull/1023


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: CXF 4.0.0 jakarta release

[Andriy Redko]

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  |  Blog
RMB>  | Old Blog
RMB>  | Github 
 |
RMB> LinkedIn  | Book
RMB> 



RMB> Le mar. 8 nov. 2022 à 13:25, Jim Ma  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 
>> 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 > >
>> > 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  |  Blog
>> > >  | Old Blog
>> > >  | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn  | Book
>> > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > >
>> > >
>> > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko  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 direc

Re: CXF 4.0.0 jakarta release

[Andriy Redko]

Here we are [1], Dan has created 4.0.0 migration guide a while back, I filled 
it a bit.
Thanks!

[1] https://cwiki.apache.org/confluence/display/CXF20DOC/4.0+Migration+Guide

Best Regards,
Andriy Redko

AR> Yes, I will create the page shortly and share on the list.

AR> Best Regards,
AR> Andriy Redko

JM>> +1 to document this when we tag the release. There is a migration guide for
JM>> each release like: https://cxf.apache.org/docs/35-migration-guide.html.
JM>> Can we add this update in the 4.0 migration guide ?

JM>> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano  
wrote:

>>> +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  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 
>>> > 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  |  Blog
>>> > > >  | Old Blog
>>> > > >  | Github <
>>> > > > https://github.com/rmannibucau> |
>>> > > > LinkedIn  | Book
>>> > > > <
>>> > > >
>>> > >
>>> >
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> > > > >
>>> > > >
>>> > > >
>>> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko  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.
>>> > > > >
>>> > > > >
>>> > > >

Re: CXF 4.0.0 jakarta release

[Andriy Redko]

Hi Jim,

I am not aware of any but @Colm is the source of truth here :-)
Thanks!

Best Regards,
Andriy Redko

> We can probably include this upgrade in the CXF 4.1 or later version after 
> it's released and get into WSS4j.
> AFAIK, there is no CXF or WSS4j issue blocked by the OpenSAML 5.0.0 upgrade.
> @Colm O hEigeartaigh  @Andriy Redko  WDYT ?

> On Mon, Nov 7, 2022 at 9:25 PM Misagh  wrote:

>> 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  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

Re: CXF 4.0.0 jakarta release

[Andriy Redko]

Yes, I will create the page shortly and share on the list.

Best Regards,
Andriy Redko

JM> +1 to document this when we tag the release. There is a migration guide for
JM> each release like: https://cxf.apache.org/docs/35-migration-guide.html.
JM> Can we add this update in the 4.0 migration guide ?

JM> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano  wrote:

>> +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  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 
>> > 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  |  Blog
>> > > >  | Old Blog
>> > > >  | Github <
>> > > > https://github.com/rmannibucau> |
>> > > > LinkedIn  | Book
>> > > > <
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > >
>> > > >
>> > > >
>> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko  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
>> > > > > ex

Re: CXF 4.0.0 jakarta release

[Jim Ma]

+1 to document this when we tag the release. There is a migration guide for
each release like: https://cxf.apache.org/docs/35-migration-guide.html.
Can we add this update in the 4.0 migration guide ?

On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano  wrote:

> +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  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 
> > 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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko  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 

Re: CXF 4.0.0 jakarta release

[Jim Ma]

On Tue, Nov 8, 2022 at 9:01 PM Romain Manni-Bucau 
wrote:

> Hi,
>
> Ok so just to clarify it means
> 1. the cxf-core split (soap, rs, integration) is postponed > 4.x
>

+1.


> 2. the compiler setting is updated to add release (current setup is only
> source/target which does not guarantee that compiled with a jdk > version
> set in pom run on a lower jdk).
>

 PR to add release to compiler plugin :
https://github.com/apache/cxf/pull/1023


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 8 nov. 2022 à 13:25, Jim Ma  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 
> > 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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko  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.
> > >

Re: CXF 4.0.0 jakarta release

[Jim Ma]

We can probably include this upgrade in the CXF 4.1 or later version after
it's released and get into WSS4j.
AFAIK, there is no CXF or WSS4j issue blocked by the OpenSAML 5.0.0 upgrade.
@Colm O hEigeartaigh   @Andriy Redko 
WDYT ?

On Mon, Nov 7, 2022 at 9:25 PM Misagh  wrote:

> 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  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
>

Re: [VOTE] - Move Apache CXF DOSGi to the attic

[Jim Ma]

+1

On Tue, Nov 8, 2022 at 10:54 PM Colm O hEigeartaigh 
wrote:

> This is a vote to move Apache CXF DOSGi to the attic. There is very
> little activity for many years now (last commit 2.5 years ago -
> https://github.com/apache/cxf-dosgi/commits/main).
>
> Previous discussion thread:
> https://lists.apache.org/thread/tjq9058n161p7fk8137nonwlfqvm9gys
>
> +1 from me.
>
> Colm.
>