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
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
