Re: [VOTE] - Release Apache CXF Build Utils 3.2.1 take2

2016-07-07 Thread Alessio Soldano
+1 Il 05/07/2016 10:57, Christian Schneider ha scritto: This is a vote to release Apache CXF Build Utils 3.2.1. It contains changes for checkstyle config to make it compatible to Eclipse Neon. In version 3.2.0 Neon shows a lot of false checkstyle errors. After my first change seemed to be i

RE: [VOTE] - Release Apache CXF Build Utils 3.2.1 take2

2016-07-07 Thread Andrei Shakirin
+1 > -Original Message- > From: Freeman Fang [mailto:freeman.f...@gmail.com] > Sent: Mittwoch, 6. Juli 2016 04:29 > To: dev@cxf.apache.org > Subject: Re: [VOTE] - Release Apache CXF Build Utils 3.2.1 take2 > > +1 > > Thanks! > - > Freeman(Yue) Fang > > Red Hat, Inc. > FuseSo

Re: [Heads up] Design of new major version of CXF DOSGi

2016-07-07 Thread Sergey Beryozkin
I'm not seeing this code in a WS provider either: https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/AbstractPojoConfigurationTypeHandler.java#L186 so it is not possible to add extra CXF interceptors for JAX-WS users too. The use-

Re: [Heads up] Design of new major version of CXF DOSGi

2016-07-07 Thread Sergey Beryozkin
Hi Christian As I said in my previous email I'd like to keep the code which works for whoever uses DOSGI JAX-RS operational so lets start from it - this code should stay, why would you remove it if you don't quite understand what it is used for :-) ? We do not need to go via a white-board di

Re: [Heads up] Design of new major version of CXF DOSGi

2016-07-07 Thread Christian Schneider
Hi Sergey, the problem is that we can not easily remove options after the major release as minor releases then should be compatible. So I would like to get rid of as many options as possible. On the other hand we need all important use cases to still work. The big problem for me is that I do

Re: [Heads up] Design of new major version of CXF DOSGi

2016-07-07 Thread Sergey Beryozkin
Hi Christian Having a POC is a good idea and given it let me suggest a slightly different path. I'd like to keep the code which is working for JAX-RS users mostly intact - if there's some code there which tries to load classes from their String names then I agree we can let it go but the cod