When to move JAX-RS Client implementation to the new module

[Sergey Beryozkin <sb...@gmail.com>]

Hi,

I've opened CXF-4696 [1] to get the client implementation moved out of 
jax-rs frontend to its own module: to get the main module smaller, to 
let users avoid downloading extra baggage when no client code is 
utilized and in preparation for implementing JAX-RS 2.0 API (though I'm 
keen on keeping supporting WebClient API, with Proxy API having no 
challenge from 2.0 API :-))

I thought I'd wait till CXF 2.8.0-SNAPSHOT but then started changing my 
mind, the reason is that CXF 2.7.x users can expect minor dependency 
changes during the lifetime of CXF 2.7.x anyway, for example, 
jsr339-api-m10 dep will get replaced soon enough by jsr339-api-m13 - 
this for the most parts will be limited just to it, to the dependency 
update.

Moving the client code to its own module will affect 2.7.x users exactly 
the same way, at some point, say, when migrating to CXF 2.7.2, they will 
need to add a new dependency but only if they also work with the client API.

IMHO this is can be simpler, as opposed to having CXF 2.7.x and 2.8.x 
jaxrs frontends still depending till some point of time on the not 
finalized 2.0 API but having the client api located in different modules...

Cheers, Sergey

[1] https://issues.apache.org/jira/browse/CXF-4696

Re: When to move JAX-RS Client implementation to the new module

[Sergey Beryozkin <sb...@gmail.com>]

On 13/12/12 12:01, Sergey Beryozkin wrote:
> Hi,
>
> I've opened CXF-4696 [1] to get the client implementation moved out of
> jax-rs frontend to its own module: to get the main module smaller, to
> let users avoid downloading extra baggage when no client code is
> utilized and in preparation for implementing JAX-RS 2.0 API (though I'm
> keen on keeping supporting WebClient API, with Proxy API having no
> challenge from 2.0 API :-))
>
> I thought I'd wait till CXF 2.8.0-SNAPSHOT but then started changing my
> mind, the reason is that CXF 2.7.x users can expect minor dependency
> changes during the lifetime of CXF 2.7.x anyway, for example,
> jsr339-api-m10 dep will get replaced soon enough by jsr339-api-m13 -
> this for the most parts will be limited just to it, to the dependency
> update.
>
> Moving the client code to its own module will affect 2.7.x users exactly
> the same way, at some point, say, when migrating to CXF 2.7.2, they will
> need to add a new dependency but only if they also work with the client
> API.
>
> IMHO this is can be simpler, as opposed to having CXF 2.7.x and 2.8.x
> jaxrs frontends still depending till some point of time on the not
> finalized 2.0 API but having the client api located in different modules...
>

After more consideration and some feedback it seems that that the best 
thing to do is to postpone it till a new 2.8.0-SNAPSHOT trunk is 
created; splitting the jaxrs frontend into 2 modules on the existing 
2.7.x trunk (and soon to become a branch) appears to be a step too 
far... I'm still planning to do some refactoring on 2.7.x (to do with 
getting ProviderFactory class a bit more manageable given that now it 
has to deal with so many providers) but getting the modules split is 
definitely will be done in 2.8.x

Updating to newer JAX-RS 2.0 milestone releases on 2.7.x is a slightly 
different issue - I'll start a new thread

Thanks, Sergey

>
> [1] https://issues.apache.org/jira/browse/CXF-4696