You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dennis Kieselhorst <de...@apache.org> on 2018/05/13 05:40:08 UTC
Start 3.3.x development
Hi,
i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot 2. There were also discussions about JAXB 2.3.0 and we might have additional changes for Java 9/10. In my view that would be a good start for CXF 3.3.x or what do you think?
Cheers
Dennis
Re: Start 3.3.x development
Posted by "John D. Ament" <jo...@apache.org>.
Sounds like a feasible approach. Agreed that right now using CXF in > Java
8 is a bit of a pain if you want to leverage the JPMS. Depending on the
provided modules isn't a good idea, highly inconsistent and makes things
harder for other EE techs (e.g. CDI).
John
On Sun, May 13, 2018 at 3:37 PM David Karlsen <da...@gmail.com>
wrote:
> I've started a few branches at work for applications (also one that is
> using cxf) - the way to fix it is to add the spec apis and jaxb as
> dependencies and it worked out fine.
>
> Maybe a spring5/boot2.x compatible release could be done for 3.3, then a
> 3.4 for java > 8?
>
> My .02$
>
> Den søn. 13. mai 2018 kl. 19:56 skrev Andriy Redko <dr...@gmail.com>:
>
> > Hey Romain,
> >
> > Spring integration indeed is not a big deal (by and large). The JAXB/SOAP
> > is. To give you some background / ideas,
> > the JAXB got moved into the dedicated module as of JDK 9 and stays like
> > that in JDK 10. So the usual approach to
> > solve this dependency issue is (among others) to add modules to compiler
> > and runtime. However, with JDK 11, the JAXB
> > module (with a dozen of others) will be removed completely. The only
> > available option would be to switch the dependencies
> > to JAXB 2.3.0 (or 2.3.1 if released, and other modules from
> > github.com/javaee). This is a risky part as CXF is used in a
> > variety of context ... What we can do also is to have a spike and
> estimate
> > the impact on the CXF with all these changes
> > incorporated, than decided for 3.3.x or keeping 3.2.x. Thoughts?
> >
> > Best Regards,
> > Andriy Redko
> >
> >
> > RMB> Hey guys
> >
> >
> > RMB> Cant an option be to use subprojects? Spring integrations sound like
> > good candidate for that and now cxf is modular it should be easier.
> > RMB> Le dim. 13 mai 2018 18:27, Andriy Redko <dr...@gmail.com> a écrit
> :
> >
> > RMB> Hi Dennis,
> >
> > RMB> In general, I think it would be great to accelerate the work in
> this
> > direction and having dedicated
> > RMB> release branch sounds like a good idea. Moreover, JDK 11 will bring
> > even more challenges for us
> > RMB> regarding the JAXB (and tons of related specs). I have been doing
> > some work related to that and from
> > RMB> dependencies perspective, it is large but envitable change (since
> > JDK 11 cuts more stuff). Same goes
> > RMB> for Spring Boot 2.0, the integration would need to be changed. The
> > concern I have though is that we
> > RMB> would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for
> > quite a while. 3.1.x is still being
> > RMB> used and we are getting requests from time to time to backport some
> > changes from 3.2.x. 3.2.x has to
> > RMB> stay for older Spring Boot integrations (1.5.x which is still
> > majority) and Java 8 (who knows for how
> > RMB> long). I would be curious to hear what Dan and other guys think,
> > since they have seen similar large
> > RMB> changes over the years. But I cerntainly agree we have to think
> > about that, dedicated branch gives
> > RMB> us more freedom to stabilize things and experiment while 3.2.x
> > serves as a stable backup.
> >
> > RMB> Thanks for bringing this up!
> >
> > RMB> Best Regards,
> > RMB> Andriy Redko
> >
> > DK>> Hi,
> >
> > DK>> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot
> > 2. There were also discussions about JAXB 2.3.0
> > DK>> and we might have additional changes for Java 9/10. In my view that
> > would be a good start for CXF 3.3.x or what do you think?
> >
> > DK>> Cheers
> > DK>> Dennis
> >
> >
> >
> >
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>
Re: Start 3.3.x development
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Only impacting stuff is jaxb which is solved adding the dependency. Not
using modules but automatic names is key to ensure portability accross all
containers and standalone modes + stay right in terms of classloading and
proxying usage. Jpms breaks everything otherwise due to the flag for
serviceloader, opens etc.
Making jaxb not used for cxf descriptor (using sax?) and optional for jaxrs
can be a first step. Forcing a transitive dep for jaxws qounds good too.
Le lun. 14 mai 2018 04:30, Dennis Kieselhorst <de...@apache.org> a écrit :
> > Maybe a spring5/boot2.x compatible release could be done for 3.3, then a
> > 3.4 for java > 8?
>
> I've already changed things so that tatest 3.2.x work with both Spring 4/
> 5 and Boot 1.5.x/ 2.x but at some point we should also deliver the latest
> versions as transitive dependencies, that's why I'm asking for the next
> significant version change.
>
> I agree that JDK/ JAXB changes will have more impact, could be also an
> idea to restructure more stuff and name it 4.x.
>
> Regards
> Dennis
>
>
>
Re: Start 3.3.x development
Posted by Dennis Kieselhorst <de...@apache.org>.
> Maybe a spring5/boot2.x compatible release could be done for 3.3, then a
> 3.4 for java > 8?
I've already changed things so that tatest 3.2.x work with both Spring 4/ 5 and Boot 1.5.x/ 2.x but at some point we should also deliver the latest versions as transitive dependencies, that's why I'm asking for the next significant version change.
I agree that JDK/ JAXB changes will have more impact, could be also an idea to restructure more stuff and name it 4.x.
Regards
Dennis
Re: Start 3.3.x development
Posted by David Karlsen <da...@gmail.com>.
I've started a few branches at work for applications (also one that is
using cxf) - the way to fix it is to add the spec apis and jaxb as
dependencies and it worked out fine.
Maybe a spring5/boot2.x compatible release could be done for 3.3, then a
3.4 for java > 8?
My .02$
Den søn. 13. mai 2018 kl. 19:56 skrev Andriy Redko <dr...@gmail.com>:
> Hey Romain,
>
> Spring integration indeed is not a big deal (by and large). The JAXB/SOAP
> is. To give you some background / ideas,
> the JAXB got moved into the dedicated module as of JDK 9 and stays like
> that in JDK 10. So the usual approach to
> solve this dependency issue is (among others) to add modules to compiler
> and runtime. However, with JDK 11, the JAXB
> module (with a dozen of others) will be removed completely. The only
> available option would be to switch the dependencies
> to JAXB 2.3.0 (or 2.3.1 if released, and other modules from
> github.com/javaee). This is a risky part as CXF is used in a
> variety of context ... What we can do also is to have a spike and estimate
> the impact on the CXF with all these changes
> incorporated, than decided for 3.3.x or keeping 3.2.x. Thoughts?
>
> Best Regards,
> Andriy Redko
>
>
> RMB> Hey guys
>
>
> RMB> Cant an option be to use subprojects? Spring integrations sound like
> good candidate for that and now cxf is modular it should be easier.
> RMB> Le dim. 13 mai 2018 18:27, Andriy Redko <dr...@gmail.com> a écrit :
>
> RMB> Hi Dennis,
>
> RMB> In general, I think it would be great to accelerate the work in this
> direction and having dedicated
> RMB> release branch sounds like a good idea. Moreover, JDK 11 will bring
> even more challenges for us
> RMB> regarding the JAXB (and tons of related specs). I have been doing
> some work related to that and from
> RMB> dependencies perspective, it is large but envitable change (since
> JDK 11 cuts more stuff). Same goes
> RMB> for Spring Boot 2.0, the integration would need to be changed. The
> concern I have though is that we
> RMB> would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for
> quite a while. 3.1.x is still being
> RMB> used and we are getting requests from time to time to backport some
> changes from 3.2.x. 3.2.x has to
> RMB> stay for older Spring Boot integrations (1.5.x which is still
> majority) and Java 8 (who knows for how
> RMB> long). I would be curious to hear what Dan and other guys think,
> since they have seen similar large
> RMB> changes over the years. But I cerntainly agree we have to think
> about that, dedicated branch gives
> RMB> us more freedom to stabilize things and experiment while 3.2.x
> serves as a stable backup.
>
> RMB> Thanks for bringing this up!
>
> RMB> Best Regards,
> RMB> Andriy Redko
>
> DK>> Hi,
>
> DK>> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot
> 2. There were also discussions about JAXB 2.3.0
> DK>> and we might have additional changes for Java 9/10. In my view that
> would be a good start for CXF 3.3.x or what do you think?
>
> DK>> Cheers
> DK>> Dennis
>
>
>
>
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: Start 3.3.x development
Posted by Andriy Redko <dr...@gmail.com>.
Hey Romain,
Spring integration indeed is not a big deal (by and large). The JAXB/SOAP is. To give you some background / ideas,
the JAXB got moved into the dedicated module as of JDK 9 and stays like that in JDK 10. So the usual approach to
solve this dependency issue is (among others) to add modules to compiler and runtime. However, with JDK 11, the JAXB
module (with a dozen of others) will be removed completely. The only available option would be to switch the dependencies
to JAXB 2.3.0 (or 2.3.1 if released, and other modules from github.com/javaee). This is a risky part as CXF is used in a
variety of context ... What we can do also is to have a spike and estimate the impact on the CXF with all these changes
incorporated, than decided for 3.3.x or keeping 3.2.x. Thoughts?
Best Regards,
Andriy Redko
RMB> Hey guys
RMB> Cant an option be to use subprojects? Spring integrations sound like good candidate for that and now cxf is modular it should be easier.
RMB> Le dim. 13 mai 2018 18:27, Andriy Redko <dr...@gmail.com> a écrit :
RMB> Hi Dennis,
RMB> In general, I think it would be great to accelerate the work in this direction and having dedicated
RMB> release branch sounds like a good idea. Moreover, JDK 11 will bring even more challenges for us
RMB> regarding the JAXB (and tons of related specs). I have been doing some work related to that and from
RMB> dependencies perspective, it is large but envitable change (since JDK 11 cuts more stuff). Same goes
RMB> for Spring Boot 2.0, the integration would need to be changed. The concern I have though is that we
RMB> would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for quite a while. 3.1.x is still being
RMB> used and we are getting requests from time to time to backport some changes from 3.2.x. 3.2.x has to
RMB> stay for older Spring Boot integrations (1.5.x which is still majority) and Java 8 (who knows for how
RMB> long). I would be curious to hear what Dan and other guys think, since they have seen similar large
RMB> changes over the years. But I cerntainly agree we have to think about that, dedicated branch gives
RMB> us more freedom to stabilize things and experiment while 3.2.x serves as a stable backup.
RMB> Thanks for bringing this up!
RMB> Best Regards,
RMB> Andriy Redko
DK>> Hi,
DK>> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot 2. There were also discussions about JAXB 2.3.0
DK>> and we might have additional changes for Java 9/10. In my view that would be a good start for CXF 3.3.x or what do you think?
DK>> Cheers
DK>> Dennis
Re: Start 3.3.x development
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hey guys
Cant an option be to use subprojects? Spring integrations sound like good
candidate for that and now cxf is modular it should be easier.
Le dim. 13 mai 2018 18:27, Andriy Redko <dr...@gmail.com> a écrit :
> Hi Dennis,
>
> In general, I think it would be great to accelerate the work in this
> direction and having dedicated
> release branch sounds like a good idea. Moreover, JDK 11 will bring even
> more challenges for us
> regarding the JAXB (and tons of related specs). I have been doing some
> work related to that and from
> dependencies perspective, it is large but envitable change (since JDK 11
> cuts more stuff). Same goes
> for Spring Boot 2.0, the integration would need to be changed. The concern
> I have though is that we
> would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for quite a
> while. 3.1.x is still being
> used and we are getting requests from time to time to backport some
> changes from 3.2.x. 3.2.x has to
> stay for older Spring Boot integrations (1.5.x which is still majority)
> and Java 8 (who knows for how
> long). I would be curious to hear what Dan and other guys think, since
> they have seen similar large
> changes over the years. But I cerntainly agree we have to think about
> that, dedicated branch gives
> us more freedom to stabilize things and experiment while 3.2.x serves as a
> stable backup.
>
> Thanks for bringing this up!
>
> Best Regards,
> Andriy Redko
>
> DK> Hi,
>
> DK> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot 2.
> There were also discussions about JAXB 2.3.0
> DK> and we might have additional changes for Java 9/10. In my view that
> would be a good start for CXF 3.3.x or what do you think?
>
> DK> Cheers
> DK> Dennis
>
>
Re: Start 3.3.x development
Posted by Andriy Redko <dr...@gmail.com>.
Hi Dennis,
In general, I think it would be great to accelerate the work in this direction and having dedicated
release branch sounds like a good idea. Moreover, JDK 11 will bring even more challenges for us
regarding the JAXB (and tons of related specs). I have been doing some work related to that and from
dependencies perspective, it is large but envitable change (since JDK 11 cuts more stuff). Same goes
for Spring Boot 2.0, the integration would need to be changed. The concern I have though is that we
would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for quite a while. 3.1.x is still being
used and we are getting requests from time to time to backport some changes from 3.2.x. 3.2.x has to
stay for older Spring Boot integrations (1.5.x which is still majority) and Java 8 (who knows for how
long). I would be curious to hear what Dan and other guys think, since they have seen similar large
changes over the years. But I cerntainly agree we have to think about that, dedicated branch gives
us more freedom to stabilize things and experiment while 3.2.x serves as a stable backup.
Thanks for bringing this up!
Best Regards,
Andriy Redko
DK> Hi,
DK> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot 2. There were also discussions about JAXB 2.3.0
DK> and we might have additional changes for Java 9/10. In my view that would be a good start for CXF 3.3.x or what do you think?
DK> Cheers
DK> Dennis