[Jersey] Re: Jersey 1.6 transitive dependencies

From: Mohan KR \(mkannapa\) <"Mohan>
Date: Wed, 13 Apr 2011 11:22:18 -0500

Just to add to this, we are also restricted in using a "specific" version of
Spring 2.5.x, as some of
the newer version has a regression, which disallows us to use the latest and
greatest Spring 2.5.x.

Typically, the lock down of transitive dependencies is managed via the
section of one's project as the authoritative source for a version when you
have different versions
of a dependency. So in my current situation, I can manage that as we have
many different spring
components that are being used in this project.

Another option you can consider is making the spring dependencies
<optional>, and then let the
users configure the dependency themselves (which would in most spring driven
projects consumers
probably are doing it). Of course this would need to be documented and
explained. (Actually the
Spring FW poms themselves make use of this tag in their dependencies)


Mohan KR

-----Original Message-----
From: Mohan KR (mkannapa) []
Sent: Wednesday, April 13, 2011 10:59 AM
Subject: RE: [Jersey] Re: Jersey 1.6 transitive dependencies

Hello Jakub,
  Yes, we are using Maven 2.0.9. (It will be a while before we upgrade).
  But then, I am using m2eclipse and the dependency resolution is *always*
done by the embedded container,
  which currently stands at 3.0.2 (I believe for m2e 0.12), but I think the
point is due to different versions of
  maven used when using CLI/IDE, and the regressions in the version ranges
from maven version to version,
  this is something that will not be consistent.

  Also, I do not agree with the assessment that a "released" artifact in
this case 1.6, should be using any
  version ranges in its dependencies (SNAPSHOTS, I can see using it). Unless
the released version guarantees
  that it will work with *every* version of spring [2.5, 3) by integrated
tests, than I can accept the use of
  version ranges, but that still means the released version need to proven
that it works with a new 2.5.x release,
  and god forbid that it actually breaks, then the release 1.6 for
jersey-spring is not honoring that contract with
  version range.

   In general, it is considered a *best practice* in Maven to *lock* down
the dependency versions at least for
   released artifacts.

Mohan KR

-----Original Message-----
From: Jakub Podlesak []
Sent: Wednesday, April 13, 2011 9:53 AM
Subject: [Jersey] Re: Jersey 1.6 transitive dependencies

Hi Mohan,

AFAIK this [2.5, 3) could indeed be ambiguous as based on the maven rules
3.0.0.RC3 falls into the [2.5, 3) version interval.

On the other hand, when i was trying to reproduce your issue, i failed
(trying with the Jersey Spring annotations example).

Maybe i am using wrong maven version (mine is 2.2.1)?
Maybe my assumption above is wrong?

Anyhow, i do not want to restrict the Spring version in the Jersey Spring
module, just in case they come up with a 2.x re-spin.

Would you be able to provide a reproducible (i know maven could be tricky in
this reproducibility) test case?



On 04/08/2011 11:05 PM, Pavel Bucek wrote:
> Hello Mohan,
> Jakub was investigating situation about spring, he already might have
> some solution or at least useful comment, so I'll let him answer.. we
> already discussed your original issue (mentioned in email with subject
> "[Jersey] jersey-spring and maven dependency issues" (adding it as an
> attachment so it wont get lost).
> Pavel
> On 4/8/11 6:09 PM, Mohan KR (mkannapa) wrote:
>> Hello Pavel,
>> jersey-spring also is pulling in newer version of Spring, I believe
>> because of use of version ranges in
>> the default profile. Can this be "locked" down to 2.5.2 (the min.
>> required) instead of a range (I had
>> sent out a note earlier regarding this).
>> (The dependency management is the relevant section from a consumer
>> side if they wish
>> to use another version of Spring 2.5.x)
>> Thanks!
>> Regards,
>> Mohan KR
>> *From:*Pavel Bucek []
>> *Sent:* Thursday, April 07, 2011 3:09 AM
>> *To:*
>> *Subject:* [Jersey] Re: Jersey 1.6 transitive dependencies
>> Hello Stephen,
>> this is definitely a bug (introduced by jersey-server modifications),
>> fixing it right now. Will be fixed in 1.7-ea02 (tomorrows promoted
>> Thanks for letting us know.
>> Regards,
>> Pavel
>> On 04/06/2011 01:14 PM, Stephen Souness wrote:
>> Hi.
>> I have just tried updating my application to use Jersey server 1.6
>> and noticed that something was bringing in javax-servlet 3.0 as a
>> dependency and including it when I deploy my web application.
>> From examining the dependency hierarchy it would appear that
>> jersey-grizzly2 (which is required for jersey-spring) is the offender.
>> I would expect such a dependency to be scoped as "provided" in the
>> pom.xml to prevent it from being included in a generated war.
>> Given that I am not intending to deploy onto a servlet 3.0 compatible
>> server, should I be concerned at introduction of an apparent
>> requirement for Servlet 3.0 functionality?
>> --
>> Stephen