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
[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]
