You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Scott Ryan <sc...@theryansplace.com> on 2007/03/02 04:11:15 UTC
Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
I am working with Maven on some fairly complex projects and I now
understand that the dependency resolution is done via a "nearness"
process rather than based on the highest compatible version. I have
recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
issue but did change the behavior a little. Here is my problem:
I have a number of framework libraries I am using including Spring,
Hibernate, etc. I have an artifact that uses Hibernate at the latest
version which in turn uses Commons-Collections 3.1. In that same
project I use some new methods out of Commons-Collections 3.2 so I
have that referenced in my pom.xml as well. The issue comes when i
try to use that artifact and another artifact that uses Hibernate.
Depending on the order that I include those dependencies I sometimes
get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time.
Now this evening I included another artifact that is using a
framework that apparently used Commons-Collections 2.1 and now my War
includes Commons-Collections 2.1 and that breaks everything. I can
see the resolution of the libraries in the -X output of the mvn
command but no idea how to fix it or why it is happening. I know I
can fix the issue by including every artifact that is used by every
other artifact in my pom.xml at the version I want but that seems to
defeat the whole purpose of transitive dependencies. There are also
cases where a dependency may read 1.7) and 1.6 and I get null
pointers during my builds even though 1.7 should be upwardly
compatible with 1.6.
So here are my questions:
Why was the "nearness" process chosen and what does it buy me over
using the most current compatible version out of my entire dependency
list?
How can I insure that I don't get my dependencies randomly downgraded
so that I get runtime errors with no indication until I use the
application?
Is there a report or process I can use to locate these downgrades so
I can deal with them during build time and not runtime?
Am I missing something or doing something wrong that is causing this
behavior?
Thanks for all the support and a great open source offering. I hope
you can educate me so I can deal with this issue and teach others.
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
Yes I have over a hundred hard versions listed in my parent pom and
it is ignoring them all during resolution except for internally
refereced dependencies which is kind of what I expected. The one
thing it does guarantee is that if all my users just put in the
groupId and artifactId without the version then it gets the version
from the parent. That allows me to control the versions we use
internally of all the open source software we use. It seems to have
no effect on the dependency resolution of artifacts that are brought
in as a result of other dependencies. I do not use any of the ( or
[ just the hard version number.
Scott
On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote:
>
> On 1 Mar 07, at 11:57 PM 1 Mar 07, Scott Ryan wrote:
>
>> Yes I did make entries in my master parent for all the versions of
>> software that we use but it is ignoring that as well.
>>
>
> You have hard versions and it's ignoring them?
>
> Jason.
>
>> Scott
>> On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote:
>>
>>> Have you tried using <dependencyManagement/> node in your parent pom
>>> to "lock down" the versions you will accept ie:
>>>
>>> <dependencyManagement>
>>> <dependencies>
>>> <dependency>
>>> <groupId>net.sf.saxon</groupId>
>>> <artifactId>saxon</artifactId>
>>> <version>[8.7]</version>
>>> </dependency>
>>> </dependencies>
>>> </dependencyManagement>
>>>
>>> Of course, this requires that you list all your dependencies
>>> (even the
>>> transitive ones) in this node and update versions etc here, but at
>>> least it centralizes things a bit...
>>>
>>> Wayne
>>>
>>> On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
>>>> I am working with Maven on some fairly complex projects and I now
>>>> understand that the dependency resolution is done via a "nearness"
>>>> process rather than based on the highest compatible version. I
>>>> have
>>>> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
>>>> issue but did change the behavior a little. Here is my problem:
>>>>
>>>> I have a number of framework libraries I am using including Spring,
>>>> Hibernate, etc. I have an artifact that uses Hibernate at the
>>>> latest
>>>> version which in turn uses Commons-Collections 3.1. In that same
>>>> project I use some new methods out of Commons-Collections 3.2 so I
>>>> have that referenced in my pom.xml as well. The issue comes when i
>>>> try to use that artifact and another artifact that uses Hibernate.
>>>> Depending on the order that I include those dependencies I
>>>> sometimes
>>>> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run
>>>> time.
>>>> Now this evening I included another artifact that is using a
>>>> framework that apparently used Commons-Collections 2.1 and now
>>>> my War
>>>> includes Commons-Collections 2.1 and that breaks everything. I can
>>>> see the resolution of the libraries in the -X output of the mvn
>>>> command but no idea how to fix it or why it is happening. I know I
>>>> can fix the issue by including every artifact that is used by every
>>>> other artifact in my pom.xml at the version I want but that
>>>> seems to
>>>> defeat the whole purpose of transitive dependencies. There are
>>>> also
>>>> cases where a dependency may read 1.7) and 1.6 and I get null
>>>> pointers during my builds even though 1.7 should be upwardly
>>>> compatible with 1.6.
>>>>
>>>> So here are my questions:
>>>>
>>>> Why was the "nearness" process chosen and what does it buy me over
>>>> using the most current compatible version out of my entire
>>>> dependency
>>>> list?
>>>> How can I insure that I don't get my dependencies randomly
>>>> downgraded
>>>> so that I get runtime errors with no indication until I use the
>>>> application?
>>>> Is there a report or process I can use to locate these
>>>> downgrades so
>>>> I can deal with them during build time and not runtime?
>>>>
>>>> Am I missing something or doing something wrong that is causing
>>>> this
>>>> behavior?
>>>>
>>>> Thanks for all the support and a great open source offering. I
>>>> hope
>>>> you can educate me so I can deal with this issue and teach others.
>>>>
>>>>
>>>> Scott Ryan
>>>> CTO Soaring Eagle L.L.C.
>>>> Denver, Co. 80129
>>>> www.soaringeagleco.com
>>>> www.theryansplace.com
>>>> (303) 263-3044
>>>> scott@theryansplace.com
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> Scott Ryan
>> CTO Soaring Eagle L.L.C.
>> Denver, Co. 80129
>> www.soaringeagleco.com
>> www.theryansplace.com
>> (303) 263-3044
>> scott@theryansplace.com
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Jason van Zyl <ja...@maven.org>.
On 1 Mar 07, at 11:57 PM 1 Mar 07, Scott Ryan wrote:
> Yes I did make entries in my master parent for all the versions of
> software that we use but it is ignoring that as well.
>
You have hard versions and it's ignoring them?
Jason.
> Scott
> On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote:
>
>> Have you tried using <dependencyManagement/> node in your parent pom
>> to "lock down" the versions you will accept ie:
>>
>> <dependencyManagement>
>> <dependencies>
>> <dependency>
>> <groupId>net.sf.saxon</groupId>
>> <artifactId>saxon</artifactId>
>> <version>[8.7]</version>
>> </dependency>
>> </dependencies>
>> </dependencyManagement>
>>
>> Of course, this requires that you list all your dependencies (even
>> the
>> transitive ones) in this node and update versions etc here, but at
>> least it centralizes things a bit...
>>
>> Wayne
>>
>> On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
>>> I am working with Maven on some fairly complex projects and I now
>>> understand that the dependency resolution is done via a "nearness"
>>> process rather than based on the highest compatible version. I have
>>> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
>>> issue but did change the behavior a little. Here is my problem:
>>>
>>> I have a number of framework libraries I am using including Spring,
>>> Hibernate, etc. I have an artifact that uses Hibernate at the
>>> latest
>>> version which in turn uses Commons-Collections 3.1. In that same
>>> project I use some new methods out of Commons-Collections 3.2 so I
>>> have that referenced in my pom.xml as well. The issue comes when i
>>> try to use that artifact and another artifact that uses Hibernate.
>>> Depending on the order that I include those dependencies I sometimes
>>> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time.
>>> Now this evening I included another artifact that is using a
>>> framework that apparently used Commons-Collections 2.1 and now my
>>> War
>>> includes Commons-Collections 2.1 and that breaks everything. I can
>>> see the resolution of the libraries in the -X output of the mvn
>>> command but no idea how to fix it or why it is happening. I know I
>>> can fix the issue by including every artifact that is used by every
>>> other artifact in my pom.xml at the version I want but that seems to
>>> defeat the whole purpose of transitive dependencies. There are also
>>> cases where a dependency may read 1.7) and 1.6 and I get null
>>> pointers during my builds even though 1.7 should be upwardly
>>> compatible with 1.6.
>>>
>>> So here are my questions:
>>>
>>> Why was the "nearness" process chosen and what does it buy me over
>>> using the most current compatible version out of my entire
>>> dependency
>>> list?
>>> How can I insure that I don't get my dependencies randomly
>>> downgraded
>>> so that I get runtime errors with no indication until I use the
>>> application?
>>> Is there a report or process I can use to locate these downgrades so
>>> I can deal with them during build time and not runtime?
>>>
>>> Am I missing something or doing something wrong that is causing this
>>> behavior?
>>>
>>> Thanks for all the support and a great open source offering. I hope
>>> you can educate me so I can deal with this issue and teach others.
>>>
>>>
>>> Scott Ryan
>>> CTO Soaring Eagle L.L.C.
>>> Denver, Co. 80129
>>> www.soaringeagleco.com
>>> www.theryansplace.com
>>> (303) 263-3044
>>> scott@theryansplace.com
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> Scott Ryan
> CTO Soaring Eagle L.L.C.
> Denver, Co. 80129
> www.soaringeagleco.com
> www.theryansplace.com
> (303) 263-3044
> scott@theryansplace.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Deploy exported-pom.xml with deploy plugin
Posted by Niels Gylling <ng...@it-practice.dk>.
I would like to release my pom info with resolved version info etc to
our shared repository.
When I install an artifact, the exported-pom.xml file is generated -
possibly if updateReleaseInfo is set to true.
Now if I perform a deploy also with the same parameter set, the pom
deployed to the shared repository is not released, ie. contains varibles
and reference to parent pom etc.
I would like this to happen as we have several parallel versions of the
same artifact, and version number of dependencies are fetched from a
parent pom - and I would hate to change the parent pom between the
parallel versions.
Now I could override the deploy plugin to suit me, but still..
Lookin at deploy-plugin source, it looks like an issue with the deploy
component.
(Still running maven 2.0.4)
/Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Rémy Sanlaville <re...@gmail.com>.
2007/3/2, Trevor Torrez <ja...@gmail.com>:
>
> > [snip]
> > Before reading that what did you think something like:
> >
> > <version>1.0</version>
> >
> > meant?
> >
> > I'm actually interested in what general user opinion is here.
> >
> > Jason.
>
>
>
> I thought it meant "1.0" (period).
So do I !
Isn't what the Better Build with Maven book explain ?
Rémy
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Trevor Torrez <ja...@gmail.com>.
> [snip]
> Before reading that what did you think something like:
>
> <version>1.0</version>
>
> meant?
>
> I'm actually interested in what general user opinion is here.
>
> Jason.
I thought it meant "1.0" (period).
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Jason van Zyl <ja...@maven.org>.
On 3 Mar 07, at 10:29 AM 3 Mar 07, Wendy Smoak wrote:
> On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> Before reading that what did you think something like:
>> <version>1.0</version>
>> meant?
>> I'm actually interested in what general user opinion is here.
>
> I suppose I've never reconciled how I thought it ought to work, with
> the actual behavior of "nearest" in the directed graph
It's not a graph unfortunately which is a fundamental mistake in the
current artifact mechanism. It needs to changed to have the graph be
a first class citizens. No reliable transformation can occur without
a graph.
> (which I like)
> coupled with the unpredictable things that would happen with
> dependencyManagement + transitivity. (Fixed in 2.0.5?)
MNG-1577 is not fixed. For 2.0.6.
>
> But how does this change things? If I declare a dependency on 1.0 and
> something two levels out declares [2.0], what do I get in my webapp?
Try it but according to what's documented it would cause a problem.
Because the only version that could be used is [2.0], if many
dependencies used hard versions then you are fundamentally screwed.
This is why the soft versions are the default and it wiggles around.
> Does [...] syntax allow transitive dependencies to override my
> choices? If everyone switches to [...] then are we back where we
> started with "nearest" ?
Well, anything down stream that uses hard versions will require
everything else to include that hard version in the range or it will
fail according to the rules.
The actual calculations to find suitable ranges requires a graph,
walking down branches and sometimes back tracking and throwing
results away. I've been looking at how Gentoo/RPM/OSGi calculate
ranges and we need something similar. We need to seriously rethink
what we have for artifact resolution.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
I actually thought that
<version>1.0</version>
meant that I was getting 1.0 of the artifact but if something else
needed a newer version then I would get that.
The problem with nearness is that you have to understand every
dependency tree for every dependency you use. It could be as in our
case that 7 layers deep into the tree far far from our code there is
an issue that is causing this downgrading. The issue we have is that
we are using Jasper Reports as well as an open source persistence
frameworks and somewhere down in the guts of those dependencies they
are walking on each other. The fix is for me to go into all those
projects and figure out what is going on and fix them in my pom.xml.
This is "ok" however I don't see the problem until run time when I
access those frameworks and they die. We ran for several days until
someone actually produced a chart and the system died.
I actually think that frameworks should not be using the [ notation
cause that is what is causing the null pointer when we include Jasper
and there is no way to override it without mucking in their pom.
I guess bottom line is we need a best practices document for
frameworks developers like apache commons and users like me so that
there is a predictable system in place with no mystery as to what we
are getting.
Scott
On Mar 3, 2007, at 8:29 AM, Wendy Smoak wrote:
> On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> Before reading that what did you think something like:
>> <version>1.0</version>
>> meant?
>> I'm actually interested in what general user opinion is here.
>
> I suppose I've never reconciled how I thought it ought to work, with
> the actual behavior of "nearest" in the directed graph (which I like)
> coupled with the unpredictable things that would happen with
> dependencyManagement + transitivity. (Fixed in 2.0.5?)
>
> But how does this change things? If I declare a dependency on 1.0 and
> something two levels out declares [2.0], what do I get in my webapp?
> Does [...] syntax allow transitive dependencies to override my
> choices? If everyone switches to [...] then are we back where we
> started with "nearest" ?
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:
> Before reading that what did you think something like:
> <version>1.0</version>
> meant?
> I'm actually interested in what general user opinion is here.
I suppose I've never reconciled how I thought it ought to work, with
the actual behavior of "nearest" in the directed graph (which I like)
coupled with the unpredictable things that would happen with
dependencyManagement + transitivity. (Fixed in 2.0.5?)
But how does this change things? If I declare a dependency on 1.0 and
something two levels out declares [2.0], what do I get in my webapp?
Does [...] syntax allow transitive dependencies to override my
choices? If everyone switches to [...] then are we back where we
started with "nearest" ?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Transitive Dependency resolution is degrading the versions
of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by "John J. Franey" <jj...@verizon.net>.
Jason van Zyl-2 wrote:
>
>
> On 2 Mar 07, at 10:36 AM 2 Mar 07, John J. Franey wrote:
>
>
>>
>>
>> From Better Builds with Maven:
>>
>>> When a version is declared as 1.1, as shown above for plexus-
>>> utils, this
>>> indicates that the
>>> preferred version of the dependency is 1.1, but that other
>>> versions may be
>>> acceptable.
>>>
>
>
> Before reading that what did you think something like:
>
> <version>1.0</version>
>
> meant?
>
> I'm actually interested in what general user opinion is here.
>
> Jason.
>
>
>
It didn't occur to me that it could mean anything other than what it says:
The project has a dependency on 1.0 (period). I guess I inferred that
dependency/version would have equivalent semantic as project/dependency.
There is no wiggle in project/version, of course; it is what it is. And so
my unchallenged guess was that dependency/version is what it is and no
deeper. Unchallenged until now: 3 months into converting ~9 ant projects to
maven, total of ~150k LOC. Yikes.
John
--
View this message in context: http://www.nabble.com/Transitive-Dependency-resolution-is-degrading-the-versions-of-my-dependencies-%28i.e.-commons-collections-3.2-down-to-2.1%29-tf3331410s177.html#a9275180
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Jason van Zyl <ja...@maven.org>.
On 2 Mar 07, at 10:36 AM 2 Mar 07, John J. Franey wrote:
>
>
> Wayne Fay wrote:
>>
>> Did you use the [...] notation in your versions?
>>
>
> The question I asked myself was "Why is the '[...]' notation
> important?".
> So I went to Better Builds with Maven (pdf) and found this in
> section 3.6:
>
>
>
>> When a version is declared as 1.1, as shown above for plexus-
>> utils, this
>> indicates that the
>> preferred version of the dependency is 1.1, but that other
>> versions may be
>> acceptable.
>>
>
> Combiningg Wayne's helpful contribution with the above, I
> understand why.
> Without the [...] notation, maven is free to choose whatever
> version. With
> the [...] notation, maven is bound to that version (or versions, if
> the
> [...] specifies a range).
>
Before reading that what did you think something like:
<version>1.0</version>
meant?
I'm actually interested in what general user opinion is here.
Jason.
> Thanks,
> John
>
>
> --
> View this message in context: http://www.nabble.com/Transitive-
> Dependency-resolution-is-degrading-the-versions-of-my-dependencies-%
> 28i.e.-commons-collections-3.2-down-to-2.1%29-
> tf3331410s177.html#a9271647
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Transitive Dependency resolution is degrading the versions
of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by "John J. Franey" <jj...@verizon.net>.
Wayne Fay wrote:
>
> Did you use the [...] notation in your versions?
>
The question I asked myself was "Why is the '[...]' notation important?".
So I went to Better Builds with Maven (pdf) and found this in section 3.6:
> When a version is declared as 1.1, as shown above for plexus-utils, this
> indicates that the
> preferred version of the dependency is 1.1, but that other versions may be
> acceptable.
>
Combiningg Wayne's helpful contribution with the above, I understand why.
Without the [...] notation, maven is free to choose whatever version. With
the [...] notation, maven is bound to that version (or versions, if the
[...] specifies a range).
Thanks,
John
--
View this message in context: http://www.nabble.com/Transitive-Dependency-resolution-is-degrading-the-versions-of-my-dependencies-%28i.e.-commons-collections-3.2-down-to-2.1%29-tf3331410s177.html#a9271647
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
When I did that I got all sorts of null pointer exceptions trying te
resolve things like 1.6 to 1.7 . I will try again today with
various combinations and see what I can get to work. It seems like a
pain to have to double check the transitive dependencies of every
artifact that I use plus every artifact that they use etc. That was
one of the pains of Maven 1 we had hoped to avoid. I will try to use
the [] notation and see how that works for me.
Thanks for all the suggestions.
Scott
On Mar 1, 2007, at 10:02 PM, Wayne Fay wrote:
> Did you use the [...] notation in your versions?
>
> Wayne
>
> On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
>> Yes I did make entries in my master parent for all the versions of
>> software that we use but it is ignoring that as well.
>>
>> Scott
>> On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote:
>>
>> > Have you tried using <dependencyManagement/> node in your parent
>> pom
>> > to "lock down" the versions you will accept ie:
>> >
>> > <dependencyManagement>
>> > <dependencies>
>> > <dependency>
>> > <groupId>net.sf.saxon</groupId>
>> > <artifactId>saxon</artifactId>
>> > <version>[8.7]</version>
>> > </dependency>
>> > </dependencies>
>> > </dependencyManagement>
>> >
>> > Of course, this requires that you list all your dependencies
>> (even the
>> > transitive ones) in this node and update versions etc here, but at
>> > least it centralizes things a bit...
>> >
>> > Wayne
>> >
>> > On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
>> >> I am working with Maven on some fairly complex projects and I now
>> >> understand that the dependency resolution is done via a "nearness"
>> >> process rather than based on the highest compatible version. I
>> have
>> >> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
>> >> issue but did change the behavior a little. Here is my problem:
>> >>
>> >> I have a number of framework libraries I am using including
>> Spring,
>> >> Hibernate, etc. I have an artifact that uses Hibernate at the
>> latest
>> >> version which in turn uses Commons-Collections 3.1. In that same
>> >> project I use some new methods out of Commons-Collections 3.2 so I
>> >> have that referenced in my pom.xml as well. The issue comes
>> when i
>> >> try to use that artifact and another artifact that uses Hibernate.
>> >> Depending on the order that I include those dependencies I
>> sometimes
>> >> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run
>> time.
>> >> Now this evening I included another artifact that is using a
>> >> framework that apparently used Commons-Collections 2.1 and now
>> my War
>> >> includes Commons-Collections 2.1 and that breaks everything. I
>> can
>> >> see the resolution of the libraries in the -X output of the mvn
>> >> command but no idea how to fix it or why it is happening. I
>> know I
>> >> can fix the issue by including every artifact that is used by
>> every
>> >> other artifact in my pom.xml at the version I want but that
>> seems to
>> >> defeat the whole purpose of transitive dependencies. There are
>> also
>> >> cases where a dependency may read 1.7) and 1.6 and I get null
>> >> pointers during my builds even though 1.7 should be upwardly
>> >> compatible with 1.6.
>> >>
>> >> So here are my questions:
>> >>
>> >> Why was the "nearness" process chosen and what does it buy me over
>> >> using the most current compatible version out of my entire
>> dependency
>> >> list?
>> >> How can I insure that I don't get my dependencies randomly
>> downgraded
>> >> so that I get runtime errors with no indication until I use the
>> >> application?
>> >> Is there a report or process I can use to locate these
>> downgrades so
>> >> I can deal with them during build time and not runtime?
>> >>
>> >> Am I missing something or doing something wrong that is causing
>> this
>> >> behavior?
>> >>
>> >> Thanks for all the support and a great open source offering. I
>> hope
>> >> you can educate me so I can deal with this issue and teach others.
>> >>
>> >>
>> >> Scott Ryan
>> >> CTO Soaring Eagle L.L.C.
>> >> Denver, Co. 80129
>> >> www.soaringeagleco.com
>> >> www.theryansplace.com
>> >> (303) 263-3044
>> >> scott@theryansplace.com
>> >>
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>>
>> Scott Ryan
>> CTO Soaring Eagle L.L.C.
>> Denver, Co. 80129
>> www.soaringeagleco.com
>> www.theryansplace.com
>> (303) 263-3044
>> scott@theryansplace.com
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Wayne Fay <wa...@gmail.com>.
Did you use the [...] notation in your versions?
Wayne
On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
> Yes I did make entries in my master parent for all the versions of
> software that we use but it is ignoring that as well.
>
> Scott
> On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote:
>
> > Have you tried using <dependencyManagement/> node in your parent pom
> > to "lock down" the versions you will accept ie:
> >
> > <dependencyManagement>
> > <dependencies>
> > <dependency>
> > <groupId>net.sf.saxon</groupId>
> > <artifactId>saxon</artifactId>
> > <version>[8.7]</version>
> > </dependency>
> > </dependencies>
> > </dependencyManagement>
> >
> > Of course, this requires that you list all your dependencies (even the
> > transitive ones) in this node and update versions etc here, but at
> > least it centralizes things a bit...
> >
> > Wayne
> >
> > On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
> >> I am working with Maven on some fairly complex projects and I now
> >> understand that the dependency resolution is done via a "nearness"
> >> process rather than based on the highest compatible version. I have
> >> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
> >> issue but did change the behavior a little. Here is my problem:
> >>
> >> I have a number of framework libraries I am using including Spring,
> >> Hibernate, etc. I have an artifact that uses Hibernate at the latest
> >> version which in turn uses Commons-Collections 3.1. In that same
> >> project I use some new methods out of Commons-Collections 3.2 so I
> >> have that referenced in my pom.xml as well. The issue comes when i
> >> try to use that artifact and another artifact that uses Hibernate.
> >> Depending on the order that I include those dependencies I sometimes
> >> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time.
> >> Now this evening I included another artifact that is using a
> >> framework that apparently used Commons-Collections 2.1 and now my War
> >> includes Commons-Collections 2.1 and that breaks everything. I can
> >> see the resolution of the libraries in the -X output of the mvn
> >> command but no idea how to fix it or why it is happening. I know I
> >> can fix the issue by including every artifact that is used by every
> >> other artifact in my pom.xml at the version I want but that seems to
> >> defeat the whole purpose of transitive dependencies. There are also
> >> cases where a dependency may read 1.7) and 1.6 and I get null
> >> pointers during my builds even though 1.7 should be upwardly
> >> compatible with 1.6.
> >>
> >> So here are my questions:
> >>
> >> Why was the "nearness" process chosen and what does it buy me over
> >> using the most current compatible version out of my entire dependency
> >> list?
> >> How can I insure that I don't get my dependencies randomly downgraded
> >> so that I get runtime errors with no indication until I use the
> >> application?
> >> Is there a report or process I can use to locate these downgrades so
> >> I can deal with them during build time and not runtime?
> >>
> >> Am I missing something or doing something wrong that is causing this
> >> behavior?
> >>
> >> Thanks for all the support and a great open source offering. I hope
> >> you can educate me so I can deal with this issue and teach others.
> >>
> >>
> >> Scott Ryan
> >> CTO Soaring Eagle L.L.C.
> >> Denver, Co. 80129
> >> www.soaringeagleco.com
> >> www.theryansplace.com
> >> (303) 263-3044
> >> scott@theryansplace.com
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> Scott Ryan
> CTO Soaring Eagle L.L.C.
> Denver, Co. 80129
> www.soaringeagleco.com
> www.theryansplace.com
> (303) 263-3044
> scott@theryansplace.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
Yes I did make entries in my master parent for all the versions of
software that we use but it is ignoring that as well.
Scott
On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote:
> Have you tried using <dependencyManagement/> node in your parent pom
> to "lock down" the versions you will accept ie:
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>net.sf.saxon</groupId>
> <artifactId>saxon</artifactId>
> <version>[8.7]</version>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> Of course, this requires that you list all your dependencies (even the
> transitive ones) in this node and update versions etc here, but at
> least it centralizes things a bit...
>
> Wayne
>
> On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
>> I am working with Maven on some fairly complex projects and I now
>> understand that the dependency resolution is done via a "nearness"
>> process rather than based on the highest compatible version. I have
>> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
>> issue but did change the behavior a little. Here is my problem:
>>
>> I have a number of framework libraries I am using including Spring,
>> Hibernate, etc. I have an artifact that uses Hibernate at the latest
>> version which in turn uses Commons-Collections 3.1. In that same
>> project I use some new methods out of Commons-Collections 3.2 so I
>> have that referenced in my pom.xml as well. The issue comes when i
>> try to use that artifact and another artifact that uses Hibernate.
>> Depending on the order that I include those dependencies I sometimes
>> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time.
>> Now this evening I included another artifact that is using a
>> framework that apparently used Commons-Collections 2.1 and now my War
>> includes Commons-Collections 2.1 and that breaks everything. I can
>> see the resolution of the libraries in the -X output of the mvn
>> command but no idea how to fix it or why it is happening. I know I
>> can fix the issue by including every artifact that is used by every
>> other artifact in my pom.xml at the version I want but that seems to
>> defeat the whole purpose of transitive dependencies. There are also
>> cases where a dependency may read 1.7) and 1.6 and I get null
>> pointers during my builds even though 1.7 should be upwardly
>> compatible with 1.6.
>>
>> So here are my questions:
>>
>> Why was the "nearness" process chosen and what does it buy me over
>> using the most current compatible version out of my entire dependency
>> list?
>> How can I insure that I don't get my dependencies randomly downgraded
>> so that I get runtime errors with no indication until I use the
>> application?
>> Is there a report or process I can use to locate these downgrades so
>> I can deal with them during build time and not runtime?
>>
>> Am I missing something or doing something wrong that is causing this
>> behavior?
>>
>> Thanks for all the support and a great open source offering. I hope
>> you can educate me so I can deal with this issue and teach others.
>>
>>
>> Scott Ryan
>> CTO Soaring Eagle L.L.C.
>> Denver, Co. 80129
>> www.soaringeagleco.com
>> www.theryansplace.com
>> (303) 263-3044
>> scott@theryansplace.com
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Wayne Fay <wa...@gmail.com>.
Have you tried using <dependencyManagement/> node in your parent pom
to "lock down" the versions you will accept ie:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>saxon</artifactId>
<version>[8.7]</version>
</dependency>
</dependencies>
</dependencyManagement>
Of course, this requires that you list all your dependencies (even the
transitive ones) in this node and update versions etc here, but at
least it centralizes things a bit...
Wayne
On 3/1/07, Scott Ryan <sc...@theryansplace.com> wrote:
> I am working with Maven on some fairly complex projects and I now
> understand that the dependency resolution is done via a "nearness"
> process rather than based on the highest compatible version. I have
> recently upgraded from Maven 2.04. to 2.0.5 which did not fix my
> issue but did change the behavior a little. Here is my problem:
>
> I have a number of framework libraries I am using including Spring,
> Hibernate, etc. I have an artifact that uses Hibernate at the latest
> version which in turn uses Commons-Collections 3.1. In that same
> project I use some new methods out of Commons-Collections 3.2 so I
> have that referenced in my pom.xml as well. The issue comes when i
> try to use that artifact and another artifact that uses Hibernate.
> Depending on the order that I include those dependencies I sometimes
> get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time.
> Now this evening I included another artifact that is using a
> framework that apparently used Commons-Collections 2.1 and now my War
> includes Commons-Collections 2.1 and that breaks everything. I can
> see the resolution of the libraries in the -X output of the mvn
> command but no idea how to fix it or why it is happening. I know I
> can fix the issue by including every artifact that is used by every
> other artifact in my pom.xml at the version I want but that seems to
> defeat the whole purpose of transitive dependencies. There are also
> cases where a dependency may read 1.7) and 1.6 and I get null
> pointers during my builds even though 1.7 should be upwardly
> compatible with 1.6.
>
> So here are my questions:
>
> Why was the "nearness" process chosen and what does it buy me over
> using the most current compatible version out of my entire dependency
> list?
> How can I insure that I don't get my dependencies randomly downgraded
> so that I get runtime errors with no indication until I use the
> application?
> Is there a report or process I can use to locate these downgrades so
> I can deal with them during build time and not runtime?
>
> Am I missing something or doing something wrong that is causing this
> behavior?
>
> Thanks for all the support and a great open source offering. I hope
> you can educate me so I can deal with this issue and teach others.
>
>
> Scott Ryan
> CTO Soaring Eagle L.L.C.
> Denver, Co. 80129
> www.soaringeagleco.com
> www.theryansplace.com
> (303) 263-3044
> scott@theryansplace.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
Thanks for the informative reply. I thought I was missing something
on the nearness thing and was hoping for a revelation that made me
excited but alas not. I am glad to see there is action on resolving
this as it could be a pretty major issue with adoption of Maven as
dependencies come and go and randomly downgrade with out a clear
indication that it has happened. We sometimes run for a day or two
before hitting the run time error. I have voted and watched the two
incidents that you pointed me to and in the meantime I will just have
to be more diligent with my dependencies.
I think it might be valuable to include it in the depedency
resolution report that is generated when running reports. Maybe with
a red flag that indicates that the dependency was downgraded. Today
that report is pretty useless for us cause we use a lot of snapshots
before our final release and the report just reports that we are
using snapshots and does nothing else beyond that.
Again thanks for the input and I have my finger crossed it will be
addressed soon.
Scott
On Mar 2, 2007, at 2:56 AM, Mark Hobson wrote:
> Hi Scott,
>
> On 02/03/07, Scott Ryan <sc...@theryansplace.com> wrote:
>> Why was the "nearness" process chosen and what does it buy me over
>> using the most current compatible version out of my entire dependency
>> list?
>
> Yep, nearness has never made much sense to me either. The proper fix
> for the more natural highest-wins strategy is covered in
> http://jira.codehaus.org/browse/MNG-612. I hope to allocate some time
> to implement this in the not-to-distant future.
>
>> How can I insure that I don't get my dependencies randomly downgraded
>> so that I get runtime errors with no indication until I use the
>> application?
>
> Dependency management would help you here, although it's broke for
> transitive dependencies ;) See
> http://jira.codehaus.org/browse/MNG-1577.
>
>> Is there a report or process I can use to locate these downgrades so
>> I can deal with them during build time and not runtime?
>
> Unfortunately, only mvn -X compile currently shows these conflicts.
> I've got plans to incorporate this very useful conflict information
> into the help:dependencies dependency tree via an optional flag.
> Alternatively, a separate dependency:conflicts goal could make more
> sense, but nothing is implemented as yet.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Mark Hobson <ma...@gmail.com>.
Hi Scott,
On 02/03/07, Scott Ryan <sc...@theryansplace.com> wrote:
> Why was the "nearness" process chosen and what does it buy me over
> using the most current compatible version out of my entire dependency
> list?
Yep, nearness has never made much sense to me either. The proper fix
for the more natural highest-wins strategy is covered in
http://jira.codehaus.org/browse/MNG-612. I hope to allocate some time
to implement this in the not-to-distant future.
> How can I insure that I don't get my dependencies randomly downgraded
> so that I get runtime errors with no indication until I use the
> application?
Dependency management would help you here, although it's broke for
transitive dependencies ;) See
http://jira.codehaus.org/browse/MNG-1577.
> Is there a report or process I can use to locate these downgrades so
> I can deal with them during build time and not runtime?
Unfortunately, only mvn -X compile currently shows these conflicts.
I've got plans to incorporate this very useful conflict information
into the help:dependencies dependency tree via an optional flag.
Alternatively, a separate dependency:conflicts goal could make more
sense, but nothing is implemented as yet.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Scott Ryan <sc...@theryansplace.com>.
Ah now I get it I need to include [ ] around my dependencies. I will
try that and see if it makes a difference. I thought that as a
general rule that versions numbers were fairly well defined. If a
project decides not to play by the generally accepted standards then
it seems that would be the exception not the rule. I would assume
that downgrading from 3.2 to 2.1 would not be an expected outcome. I
do see that many of the apache projects use the 2nd position as a
compatible version and only use 2 rather than 3 numbers. I would
assume that most projects follow the rule that changes in the 2 or 3
position represent changes that are upwardly compatible for example
1.6.2 can be use in place of 1.6.1 and 1.7 can be used in place of
1.6. However even if projects are not following the standard I would
expect the system to be more stable if you replace 2.1 with 3.2 and
deal with those issues rather than replacing 3.2 with 2.1 and knowing
it will break.
Maybe a simple report we can run on the system that would indicate
any downgrades that are being done by Maven with a red star so that
we are aware the change is taking place and can resolve them
manually. I personally would expect the system to always upgrade my
dependencies and never downgrade them. Upgrading will seldom yield
an issue and if it can be identified and dealt with then that is even
better. Downgrading will always yield an issue and mean that you
will always have issues that you must deal with.
Why won't a simple version match work when resolving dependencies.
1.6 replaces 1.7 , 3.2 replaces 2.1 and then warn the user via a
report or message that they need to check the dependencies and allow
them to override the change. SInce most of the time we cannot
control the nearness without putting all the dependencies in our
local project it seems to be we are back to the Maven 1 approach of
including all dependencies including transitive ones in our project
otherwise we run the risk of introducing runtime errors.
Any way that is my 2 cents. I still think you guys built an awesome
system and I just need to work out the quirks with very large and
complex projects. As I learn more about what the system does I can
make changes to adapt. It is important to get the information out so
that people realize what can happen and what to look for. We can
develop reports to help people find and address situations like I
have encountered.
Thanks for the help and I will test the change to hard dependencies
on Monday and see what that yields us. At least i can fix the issue
in one location rather than having to include a bunch of bogus
dependencies in all of our projects.
Thanks again for the information and suggestions.
Scott Ryan
On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote:
>
> On 1 Mar 07, at 10:11 PM 1 Mar 07, Scott Ryan wrote:
>
>> I am working with Maven on some fairly complex projects and I now
>> understand that the dependency resolution is done via a "nearness"
>> process rather than based on the highest compatible version. I
>> have recently upgraded from Maven 2.04. to 2.0.5 which did not fix
>> my issue but did change the behavior a little. Here is my problem:
>>
>> I have a number of framework libraries I am using including
>> Spring, Hibernate, etc. I have an artifact that uses Hibernate at
>> the latest version which in turn uses Commons-Collections 3.1. In
>> that same project I use some new methods out of Commons-
>> Collections 3.2 so I have that referenced in my pom.xml as well.
>> The issue comes when i try to use that artifact and another
>> artifact that uses Hibernate. Depending on the order that I
>> include those dependencies I sometimes get 3.1 and sometimes 3.2.
>> If I get 3.1 my code breaks at run time. Now this evening I
>> included another artifact that is using a framework that
>> apparently used Commons-Collections 2.1 and now my War includes
>> Commons-Collections 2.1 and that breaks everything. I can see the
>> resolution of the libraries in the -X output of the mvn command
>> but no idea how to fix it or why it is happening. I know I can
>> fix the issue by including every artifact that is used by every
>> other artifact in my pom.xml at the version I want but that seems
>> to defeat the whole purpose of transitive dependencies. There are
>> also cases where a dependency may read 1.7) and 1.6 and I get null
>> pointers during my builds even though 1.7 should be upwardly
>> compatible with 1.6.
>>
>> So here are my questions:
>>
>> Why was the "nearness" process chosen and what does it buy me over
>> using the most current compatible version out of my entire
>> dependency list?
>
> It is impossible for us to know what the most current compatible
> version is. A lot of groups are careless with API changes and for a
> first take we decided that you know what you need to use so any
> specification closest to your project wins. Almost no work has been
> done on the artifact resolution system since our first assumption,
> but some pluggable strategies would be good.
>
>> How can I insure that I don't get my dependencies randomly
>> downgraded so that I get runtime errors with no indication until I
>> use the application?
>
> Unfortunately when you specify "1.0" in an element like
> <version>1.0</version> that is really a soft requirement and it can
> wiggle around. In order to specify a hard requirement you must use
> [1.0] which means that's the only thing you want. A soft version is
> a little more flexible and will find something that accommodates
> all ranges. I feel that this is someone counter intuitive for the
> average user looking at a POM. If you want a hard requirement then
> you must use [1.0].
>
>> Is there a report or process I can use to locate these downgrades
>> so I can deal with them during build time and not runtime?
>
> There is a dependency report.
>
>>
>> Am I missing something or doing something wrong that is causing
>> this behavior?
>
> I believe it is the misconception that "1.0" is a hard version.
>
>>
>> Thanks for all the support and a great open source offering. I
>> hope you can educate me so I can deal with this issue and teach
>> others.
>>
>>
>> Scott Ryan
>> CTO Soaring Eagle L.L.C.
>> Denver, Co. 80129
>> www.soaringeagleco.com
>> www.theryansplace.com
>> (303) 263-3044
>> scott@theryansplace.com
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Posted by Jason van Zyl <ja...@maven.org>.
On 1 Mar 07, at 10:11 PM 1 Mar 07, Scott Ryan wrote:
> I am working with Maven on some fairly complex projects and I now
> understand that the dependency resolution is done via a "nearness"
> process rather than based on the highest compatible version. I
> have recently upgraded from Maven 2.04. to 2.0.5 which did not fix
> my issue but did change the behavior a little. Here is my problem:
>
> I have a number of framework libraries I am using including Spring,
> Hibernate, etc. I have an artifact that uses Hibernate at the
> latest version which in turn uses Commons-Collections 3.1. In that
> same project I use some new methods out of Commons-Collections 3.2
> so I have that referenced in my pom.xml as well. The issue comes
> when i try to use that artifact and another artifact that uses
> Hibernate. Depending on the order that I include those
> dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1
> my code breaks at run time. Now this evening I included another
> artifact that is using a framework that apparently used Commons-
> Collections 2.1 and now my War includes Commons-Collections 2.1 and
> that breaks everything. I can see the resolution of the libraries
> in the -X output of the mvn command but no idea how to fix it or
> why it is happening. I know I can fix the issue by including every
> artifact that is used by every other artifact in my pom.xml at the
> version I want but that seems to defeat the whole purpose of
> transitive dependencies. There are also cases where a dependency
> may read 1.7) and 1.6 and I get null pointers during my builds even
> though 1.7 should be upwardly compatible with 1.6.
>
> So here are my questions:
>
> Why was the "nearness" process chosen and what does it buy me over
> using the most current compatible version out of my entire
> dependency list?
It is impossible for us to know what the most current compatible
version is. A lot of groups are careless with API changes and for a
first take we decided that you know what you need to use so any
specification closest to your project wins. Almost no work has been
done on the artifact resolution system since our first assumption,
but some pluggable strategies would be good.
> How can I insure that I don't get my dependencies randomly
> downgraded so that I get runtime errors with no indication until I
> use the application?
Unfortunately when you specify "1.0" in an element like <version>1.0</
version> that is really a soft requirement and it can wiggle around.
In order to specify a hard requirement you must use [1.0] which means
that's the only thing you want. A soft version is a little more
flexible and will find something that accommodates all ranges. I
feel that this is someone counter intuitive for the average user
looking at a POM. If you want a hard requirement then you must use
[1.0].
> Is there a report or process I can use to locate these downgrades
> so I can deal with them during build time and not runtime?
There is a dependency report.
>
> Am I missing something or doing something wrong that is causing
> this behavior?
I believe it is the misconception that "1.0" is a hard version.
>
> Thanks for all the support and a great open source offering. I
> hope you can educate me so I can deal with this issue and teach
> others.
>
>
> Scott Ryan
> CTO Soaring Eagle L.L.C.
> Denver, Co. 80129
> www.soaringeagleco.com
> www.theryansplace.com
> (303) 263-3044
> scott@theryansplace.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org