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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
[EMAIL PROTECTED]