[GitHub] [cxf] jimma commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

jimma commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016271239


##
distribution/src/main/release/samples/pom.xml:
##
@@ -240,108 +289,8 @@
 
 
 
-
-java9-plus
-
-[9,)
-
-
-
-jakarta.xml.bind
-jakarta.xml.bind-api
-
-
-jakarta.annotation
-jakarta.annotation-api
-
-
-jakarta.xml.ws
-jakarta.xml.ws-api
-
-
-jakarta.activation
-jakarta.activation-api
-2.1.0
-
-
-jakarta.jws
-jakarta.jws-api
-
-
-com.sun.xml.messaging.saaj
-saaj-impl
-2.0.1
-runtime
-
-
-org.glassfish.jaxb
-jaxb-runtime
-
-
-org.glassfish.jaxb
-jaxb-xjc
-
-
-org.glassfish.corba
-glassfish-corba-orb
-4.2.2
-
-
-
-
-
-
-jakarta

Review Comment:
   Thanks for the update @reta . I added back this profile with a better 
profile name `spring`. The https://issues.apache.org/jira/browse/CXF-8788 is 
created to remove this profile after the final release comes out in the coming 
weeks.



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

[Jim Ma]

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 direction IMHO.
> > >
> > > > 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 à 18:06, Freeman Fang  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 
> > 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

Re: CXF 4.0.0 jakarta release

[Romain Manni-Bucau]

Hi,

Ok so just to clarify it means
1. the cxf-core split (soap, rs, integration) is postponed > 4.x
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).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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 direction IMHO.
> > > >
> > > > > 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
> > > > >
> > > >
> > > >
> > > 

[GitHub] [cxf] reta commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

reta commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016645795


##
distribution/src/main/release/samples/pom.xml:
##
@@ -240,108 +289,8 @@
 
 
 
-
-java9-plus
-
-[9,)
-
-
-
-jakarta.xml.bind
-jakarta.xml.bind-api
-
-
-jakarta.annotation
-jakarta.annotation-api
-
-
-jakarta.xml.ws
-jakarta.xml.ws-api
-
-
-jakarta.activation
-jakarta.activation-api
-2.1.0
-
-
-jakarta.jws
-jakarta.jws-api
-
-
-com.sun.xml.messaging.saaj
-saaj-impl
-2.0.1
-runtime
-
-
-org.glassfish.jaxb
-jaxb-runtime
-
-
-org.glassfish.jaxb
-jaxb-xjc
-
-
-org.glassfish.corba
-glassfish-corba-orb
-4.2.2
-
-
-
-
-
-
-jakarta

Review Comment:
   @jimma the `jakarta` name is being used in Jenkins builds and the same 
profile is also present in 
[pom.xml](https://github.com/apache/cxf/blob/main/pom.xml#L426). Could you 
please rename it back to `jakarta` so we don't need to change jobs 
configurations? (fe we run `-Peverything,jakarta`)



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

[GitHub] [cxf] jimma commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

jimma commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016662070


##
distribution/src/main/release/samples/pom.xml:
##
@@ -240,108 +289,8 @@
 
 
 
-
-java9-plus
-
-[9,)
-
-
-
-jakarta.xml.bind
-jakarta.xml.bind-api
-
-
-jakarta.annotation
-jakarta.annotation-api
-
-
-jakarta.xml.ws
-jakarta.xml.ws-api
-
-
-jakarta.activation
-jakarta.activation-api
-2.1.0
-
-
-jakarta.jws
-jakarta.jws-api
-
-
-com.sun.xml.messaging.saaj
-saaj-impl
-2.0.1
-runtime
-
-
-org.glassfish.jaxb
-jaxb-runtime
-
-
-org.glassfish.jaxb
-jaxb-xjc
-
-
-org.glassfish.corba
-glassfish-corba-orb
-4.2.2
-
-
-
-
-
-
-jakarta

Review Comment:
   @reta Thanks for review. Changed back . I saw this profile is set to 
`activeByDefault`. Do we still need to active this profile with -P flag ? 



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

[GitHub] [cxf] reta commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

reta commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016671480


##
distribution/src/main/release/samples/pom.xml:
##
@@ -240,108 +289,8 @@
 
 
 
-
-java9-plus
-
-[9,)
-
-
-
-jakarta.xml.bind
-jakarta.xml.bind-api
-
-
-jakarta.annotation
-jakarta.annotation-api
-
-
-jakarta.xml.ws
-jakarta.xml.ws-api
-
-
-jakarta.activation
-jakarta.activation-api
-2.1.0
-
-
-jakarta.jws
-jakarta.jws-api
-
-
-com.sun.xml.messaging.saaj
-saaj-impl
-2.0.1
-runtime
-
-
-org.glassfish.jaxb
-jaxb-runtime
-
-
-org.glassfish.jaxb
-jaxb-xjc
-
-
-org.glassfish.corba
-glassfish-corba-orb
-4.2.2
-
-
-
-
-
-
-jakarta

Review Comment:
   I think when profiles are used explicitly (like fe `-P`), the 
`activeByDefault` is not respected (since it is not default anymore). If you 
are curious, it is simple to check:
   
   ```
   $ mvn help:active-profiles
   ```
   
   vs explicit profiles with `-P` (this command fails for me, the `jakarta` 
profile is not picked up anymore)
   
   ```
   $ mvn help:active-profiles -Peverything
   ```



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

[GitHub] [cxf] reta commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

reta commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016673152


##
pom.xml:
##
@@ -217,10 +217,9 @@
 maven-compiler-plugin
 3.10.1
 
-${cxf.jdk.version}
-${cxf.jdk.version}
 256M
 ${cxf.compiler.fork}
+11

Review Comment:
   Super minor, we could set it to `${cxf.jdk.version}` (it is 11)



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

[GitHub] [cxf] reta commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

reta commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1016673152


##
pom.xml:
##
@@ -217,10 +217,9 @@
 maven-compiler-plugin
 3.10.1
 
-${cxf.jdk.version}
-${cxf.jdk.version}
 256M
 ${cxf.compiler.fork}
+11

Review Comment:
   Super minor, we could set it to `${cxf.jdk.version}` (it is 11), it would be 
less of hurdle to move on to different JDKs later on



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

[VOTE] - Move Apache CXF DOSGi to the attic

[Colm O hEigeartaigh]

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.

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

[Jeff Genender]

+1

Jeff

> On Nov 8, 2022, at 7:54 AM, 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.

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

[Freeman Fang]

+1
Thanks!

Freeman

On Tue, Nov 8, 2022 at 9:54 AM 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.
>

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

[Andriy Redko]

+1, thanks Colm!

Best Regards,
Andriy Redko

COh> This is a vote to move Apache CXF DOSGi to the attic. There is very
COh> little activity for many years now (last commit 2.5 years ago -
COh> https://github.com/apache/cxf-dosgi/commits/main).

COh> Previous discussion thread:
COh> https://lists.apache.org/thread/tjq9058n161p7fk8137nonwlfqvm9gys

COh> +1 from me.

COh> Colm.

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

[Alessio Soldano]

+1

Thanks

On Tue, Nov 8, 2022 at 3:59 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.
>
>

Re: CXF 4.0.0 jakarta release

[Alessio Soldano]

+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  >
> > 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  |  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 à 18:06, Freeman Fang 
> a
> > > > écrit :
> > > >
> > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > > since we
> 

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

[Dennis Kieselhorst]

+1

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

[Alexey Markevich]

+1

On 11/8/22, Dennis Kieselhorst  wrote:
> +1
>

[GitHub] [cxf] jimma commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

jimma commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1017328226


##
pom.xml:
##
@@ -217,10 +217,9 @@
 maven-compiler-plugin
 3.10.1
 
-${cxf.jdk.version}
-${cxf.jdk.version}
 256M
 ${cxf.compiler.fork}
+11

Review Comment:
   @reta I wrongly committed some experimental stuff. Reverted.  I should 
changed this with another PR and JIRA issue.



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

[GitHub] [cxf] jimma commented on a diff in pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

jimma commented on code in PR #1022:
URL: https://github.com/apache/cxf/pull/1022#discussion_r1017332870


##
distribution/src/main/release/samples/pom.xml:
##
@@ -240,108 +289,8 @@
 
 
 
-
-java9-plus
-
-[9,)
-
-
-
-jakarta.xml.bind
-jakarta.xml.bind-api
-
-
-jakarta.annotation
-jakarta.annotation-api
-
-
-jakarta.xml.ws
-jakarta.xml.ws-api
-
-
-jakarta.activation
-jakarta.activation-api
-2.1.0
-
-
-jakarta.jws
-jakarta.jws-api
-
-
-com.sun.xml.messaging.saaj
-saaj-impl
-2.0.1
-runtime
-
-
-org.glassfish.jaxb
-jaxb-runtime
-
-
-org.glassfish.jaxb
-jaxb-xjc
-
-
-org.glassfish.corba
-glassfish-corba-orb
-4.2.2
-
-
-
-
-
-
-jakarta

Review Comment:
   @reta I didn't know this and learned new thing.  Thanks. 



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

[GitHub] [cxf] jimma merged pull request #1022: [CXF-8787]:Fix sample build failures

[GitBox]

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


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