Confused by Jersey Dependencies

[Robert DiFalco]

I can't quite figure out how to get the Jersey Dependencies right.

I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2)
features in my code and I also use Bean Validation.

It seems like no matter WHAT I do that client comes in for the compile
scope (I know it comes in for test). Is this expected? Maybe it is and I
just got confused by the docs.

It seems like jersey-server and jersey-validation will both bring in
jersey-client. Correct? Is the idea that you cannot build a server without
the client?

Here's what's in my pom.xml.

<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Robert DiFalco]

Anyone have any thoughts on this?

Post by Robert DiFalco
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2)
features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile
scope (I know it comes in for test). Is this expected? Maybe it is and I
just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in
jersey-client. Correct? Is the idea that you cannot build a server without
the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Marek Potociar]

Run mvn dependency:tree and it should be clear where your dependencies come from.

Marek

Post by Robert DiFalco
Anyone have any thoughts on this?
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile scope (I know it comes in for test). Is this expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in jersey-client. Correct? Is the idea that you cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Robert DiFalco]

I understand where it comes from, I was asking why a Jersey server needs to
include the jersey-client jar and if there is any way to avoid it? I
thought maybe you guys made a mistake when creating your transitive
dependencies.

[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile




On Tue, Mar 25, 2014 at 8:44 AM, Marek Potociar

Post by Marek Potociar
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek
Anyone have any thoughts on this?

Post by Robert DiFalco
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2)
features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile
scope (I know it comes in for test). Is this expected? Maybe it is and I
just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in
jersey-client. Correct? Is the idea that you cannot build a server without
the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Marek Potociar]

No mistake. Jersey server supports injection of client artifacts. Thus the dependency.

Marek

I understand where it comes from, I was asking why a Jersey server needs to include the jersey-client jar and if there is any way to avoid it? I thought maybe you guys made a mistake when creating your transitive dependencies.
[INFO] +- org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +- org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek

Post by Robert DiFalco
Anyone have any thoughts on this?
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile scope (I know it comes in for test). Is this expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in jersey-client. Correct? Is the idea that you cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[cowwoc]

Couldn't the injection Provider(s) reside in the client module? I assume
the auto-registration process would pick them up on the classpath.

Gili

Post by Marek Potociar
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek

Post by Robert DiFalco
I understand where it comes from, I was asking why a Jersey server
needs to include the jersey-client jar and if there is any way to
avoid it? I thought maybe you guys made a mistake when creating your
transitive dependencies.
[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
On Tue, Mar 25, 2014 at 8:44 AM, Marek Potociar
Run mvn dependency:tree and it should be clear where your
dependencies come from.
Marek
On 24 Mar 2014, at 21:46, Robert DiFalco

Post by Robert DiFalco
Anyone have any thoughts on this?
On Thu, Mar 20, 2014 at 8:36 PM, Robert DiFalco
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as
well as HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for
the compile scope (I know it comes in for test). Is this
expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both
bring in jersey-client. Correct? Is the idea that you cannot
build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Robert DiFalco]

Alright, so you if you have a Jersey Server or a Jersey Server that also
uses the Jersey Client code their dependencies would be the same? I'm fine
with that just making sure I understand. I got the impression you needed to
include the client jar if you were going to use client features. But maybe
that is if you are going to use client ONLY features.

Post by cowwoc
Couldn't the injection Provider(s) reside in the client module? I assume
the auto-registration process would pick them up on the classpath.
Gili
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek
I understand where it comes from, I was asking why a Jersey server needs
to include the jersey-client jar and if there is any way to avoid it? I
thought maybe you guys made a mistake when creating your transitive
dependencies.
[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile

Post by Marek Potociar
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek
Anyone have any thoughts on this?

Post by Robert DiFalco
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as
HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile
scope (I know it comes in for test). Is this expected? Maybe it is and I
just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in
jersey-client. Correct? Is the idea that you cannot build a server without
the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Marek Potociar]

There is only a single JAX-RS API and that contains both - client and server APIs. It is natural to expect that people who develop server-side JAX-RS resources may in their code want to use the JAX-RS client APIs. We cannot provide support for JAX-RS client APIs without referencing the jersey client module.

So you seem to understand it correctly - the client jar is for client ONLY. The server jar depends on client jar as it is covering the whole JAX-RS API. Since there is a transitive dependency from server to client jar, you do not need to declare the client dependency explicitly in your code that depends on server jar. In any case it is still a good practice to explicitly declare all the dependencies, esp. if you decide to use client APIs from your server-side code.

Marek

Alright, so you if you have a Jersey Server or a Jersey Server that also uses the Jersey Client code their dependencies would be the same? I'm fine with that just making sure I understand. I got the impression you needed to include the client jar if you were going to use client features. But maybe that is if you are going to use client ONLY features.
Couldn't the injection Provider(s) reside in the client module? I assume the auto-registration process would pick them up on the classpath.
Gili

Post by Marek Potociar
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek

I understand where it comes from, I was asking why a Jersey server needs to include the jersey-client jar and if there is any way to avoid it? I thought maybe you guys made a mistake when creating your transitive dependencies.
[INFO] +- org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +- org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek

Post by Robert DiFalco
Anyone have any thoughts on this?
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile scope (I know it comes in for test). Is this expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in jersey-client. Correct? Is the idea that you cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Robert DiFalco]

Great explanation, thanks Marek.


On Wed, Mar 26, 2014 at 4:11 AM, Marek Potociar

Post by Marek Potociar
There is only a single JAX-RS API and that contains both - client and
server APIs. It is natural to expect that people who develop server-side
JAX-RS resources may in their code want to use the JAX-RS client APIs. We
cannot provide support for JAX-RS client APIs without referencing the
jersey client module.
So you seem to understand it correctly - the client jar is for client
ONLY. The server jar depends on client jar as it is covering the whole
JAX-RS API. Since there is a transitive dependency from server to client
jar, you do not need to declare the client dependency explicitly in your
code that depends on server jar. In any case it is still a good practice to
explicitly declare all the dependencies, esp. if you decide to use client
APIs from your server-side code.
Marek
Alright, so you if you have a Jersey Server or a Jersey Server that also
uses the Jersey Client code their dependencies would be the same? I'm fine
with that just making sure I understand. I got the impression you needed to
include the client jar if you were going to use client features. But maybe
that is if you are going to use client ONLY features.

Post by cowwoc
Couldn't the injection Provider(s) reside in the client module? I
assume the auto-registration process would pick them up on the classpath.
Gili
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek
I understand where it comes from, I was asking why a Jersey server
needs to include the jersey-client jar and if there is any way to avoid it?
I thought maybe you guys made a mistake when creating your transitive
dependencies.
[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
On Tue, Mar 25, 2014 at 8:44 AM, Marek Potociar <

Post by Marek Potociar
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek
Anyone have any thoughts on this?
On Thu, Mar 20, 2014 at 8:36 PM, Robert DiFalco <

Post by Robert DiFalco
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as
HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the
compile scope (I know it comes in for test). Is this expected? Maybe it is
and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in
jersey-client. Correct? Is the idea that you cannot build a server without
the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[Marek Potociar]

Then the dependency would be backwards as the provider relies on internal server APIs. This way it makes more sense.

Marek

Couldn't the injection Provider(s) reside in the client module? I assume the auto-registration process would pick them up on the classpath.
Gili

Post by Marek Potociar
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek

I understand where it comes from, I was asking why a Jersey server needs to include the jersey-client jar and if there is any way to avoid it? I thought maybe you guys made a mistake when creating your transitive dependencies.
[INFO] +- org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +- org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
[INFO] | | \- org.glassfish.jersey.core:jersey-client:jar:2.7:compile
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
Run mvn dependency:tree and it should be clear where your dependencies come from.
Marek

Post by Robert DiFalco
Anyone have any thoughts on this?
I can't quite figure out how to get the Jersey Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey (as well as HK2) features in my code and I also use Bean Validation.
It seems like no matter WHAT I do that client comes in for the compile scope (I know it comes in for test). Is this expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will both bring in jersey-client. Correct? Is the idea that you cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[cowwoc]

Got it.

Thanks for the clarification.

Gili

Post by Marek Potociar
Then the dependency would be backwards as the provider relies on
internal server APIs. This way it makes more sense.
Marek

Post by cowwoc
Couldn't the injection Provider(s) reside in the client module? I
assume the auto-registration process would pick them up on the classpath.
Gili

Post by Marek Potociar
No mistake. Jersey server supports injection of client artifacts. Thus the dependency.
Marek

Post by Robert DiFalco
I understand where it comes from, I was asking why a Jersey server
needs to include the jersey-client jar and if there is any way to
avoid it? I thought maybe you guys made a mistake when creating
your transitive dependencies.
[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \-
org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \-
org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
On Tue, Mar 25, 2014 at 8:44 AM, Marek Potociar
Run mvn dependency:tree and it should be clear where your
dependencies come from.
Marek
On 24 Mar 2014, at 21:46, Robert DiFalco

Post by Robert DiFalco
Anyone have any thoughts on this?
On Thu, Mar 20, 2014 at 8:36 PM, Robert DiFalco
I can't quite figure out how to get the Jersey
Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey
(as well as HK2) features in my code and I also use Bean
Validation.
It seems like no matter WHAT I do that client comes in for
the compile scope (I know it comes in for test). Is this
expected? Maybe it is and I just got confused by the docs.
It seems like jersey-server and jersey-validation will
both bring in jersey-client. Correct? Is the idea that you
cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>

[cowwoc]

On second thought... I think we can do better. If we extracted the
provider-related code into its own module, then client and server would
depend on that and the client-specific injection could be moved into the
client module and the server code would no longer need to depend on the
client.

I filed https://java.net/jira/browse/JERSEY-2488 which explains why this
is important.

Gili

Post by cowwoc
Got it.
Thanks for the clarification.
Gili

Post by Marek Potociar
Then the dependency would be backwards as the provider relies on
internal server APIs. This way it makes more sense.
Marek

Post by cowwoc
Couldn't the injection Provider(s) reside in the client module? I
assume the auto-registration process would pick them up on the classpath.
Gili

Post by Marek Potociar
No mistake. Jersey server supports injection of client artifacts.
Thus the dependency.
Marek

Post by Robert DiFalco
I understand where it comes from, I was asking why a Jersey server
needs to include the jersey-client jar and if there is any way to
avoid it? I thought maybe you guys made a mistake when creating
your transitive dependencies.
[INFO] +-
org.glassfish.jersey.containers:jersey-container-grizzly2-http:jar:2.7:compile
[INFO] | +- org.glassfish.hk2.external:javax.inject:jar:2.2.0:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.7:compile
[INFO] | | +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] | | +-
org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.7:compile
[INFO] | | +- org.glassfish.hk2:hk2-api:jar:2.2.0:compile
[INFO] | | | +- org.glassfish.hk2:hk2-utils:jar:2.2.0:compile
[INFO] | | | \-
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.2.0:compile
[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.2.0:compile
[INFO] | | | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] | | \-
org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.7:compile
*[INFO] | | \-
org.glassfish.jersey.core:jersey-client:jar:2.7:compile*
[INFO] | \- javax.ws.rs:javax.ws.rs-api:jar:2.0:compile
On Tue, Mar 25, 2014 at 8:44 AM, Marek Potociar
Run mvn dependency:tree and it should be clear where your
dependencies come from.
Marek
On 24 Mar 2014, at 21:46, Robert DiFalco

Post by Robert DiFalco
Anyone have any thoughts on this?
On Thu, Mar 20, 2014 at 8:36 PM, Robert DiFalco
I can't quite figure out how to get the Jersey
Dependencies right.
I am creating a Grizzly-HTTP jersey app. I do use jersey
(as well as HK2) features in my code and I also use Bean
Validation.
It seems like no matter WHAT I do that client comes in
for the compile scope (I know it comes in for test). Is
this expected? Maybe it is and I just got confused by the
docs.
It seems like jersey-server and jersey-validation will
both bring in jersey-client. Correct? Is the idea that
you cannot build a server without the client?
Here's what's in my pom.xml.
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-server</artifactId>
<version>${grizzly-http-server.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-http</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>${jersey.version}</version>
</dependency>