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.
Thanks!
Regards,
Mohan KR
-----Original Message-----
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Wednesday, April 13, 2011 9:53 AM
To: users_at_jersey.java.net
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
IIUC
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?
Thanks,
~Jakub
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 [mailto:pavel.bucek_at_oracle.com]
>> *Sent:* Thursday, April 07, 2011 3:09 AM
>> *To:* users_at_jersey.java.net
>> *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
build).
>>
>> 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
>>
>