We have several web services clients that are pulling in jersey-client,
which pulls in jersey-core as a transitive dependency. Since the Maven
coordinates and package structure for Jersey 1.x and Jersey 2 are
different, both need to be on the classpath for compatibility.
There are two cases we're concerned about:
1) We have a Jersey 2.0 web service that needs to use client jars from
Jersey 1.x services to communicate with them
2) We have another application with multiple client jars, some of which
potentially being Jersey 2 or Jersey 1.x
If the jax-rs dependency was transitive in Jersey 1.x this wouldn't be a
problem, as that could be managed through dependency management and my
understanding is that Jersey 1.x can use the jax-rs 2.0 classes.
There's a cost to updating all of our Jersey 1.x services to 2.0, and one
that we cannot afford up front; we need to be able to update as we have
opportunities to do so.
Again, I'm questioning if I'm overlooking some glaring issue here, so feel
free to set me straight if I am :)
On Tue, Jun 18, 2013 at 9:23 AM, Marek Potociar
<marek.potociar_at_oracle.com>wrote:
> Hi,
>
> Please feel free to file a new issue against Jersey 1.x. We do not however
> have any immediate plans to release new Jersey 1.x version that would fix
> the issue. Just curious - what forces you to have both Jersey 1.x and
> JAX-RS 2.0 on the same class path?
>
> Marek
>
> On Jun 17, 2013, at 7:26 PM, Ian Simpson <ian.g.simpson_at_gmail.com> wrote:
>
> I'm looking at using Jersey 2.0 and I'm trying to tackle the issue of
> having both the 1.x and 2.x jax-rs classes within the same classpath.
>
> The jersey-core Maven dependencies for 1.x all bundle the jax-rs classes
> inside, which is undesirable from a class loading standpoint when using
> Jersey 2.x since you need jax-rs 2.0. There's an excellent blog post
> outlining this concern here:
> http://sleeplessinslc.blogspot.com/2012/10/jax-rs-20-jersey-20-preview-example.html
>
> JUnit has a similar issue with including hamcrest, which creates issues if
> you use Maven to block duplicate classes. There's also a junit-dep jar
> that's available which doesn't include this package.
>
> Can a similar thing be done retroactively and deployed to Maven central
> for the Jersey 1.x jars? Perhaps create a jersey-core-nodeps or something
> along those lines? I could repackage the jars myself and upload them to my
> organization's internal Nexus instance, but it would be preferable to have
> them available via Central.
>
> I'm also open to the fact that I may be missing the obvious solution or an
> easy alternative. If that's the case please call out my obliviousness.
>
>
>