Hi Everyone
In the spirit of full-disclosure, I work with Ian at Overstock.com,
but I wanted to chime in on this discussion because of issues I've
had with various projects.
Given this scenario:
com.foo:my-artifact:jar:1.0:compile
org.hibernate:hibernate:3.1.1:compile
com.foo:another-artifact:2.0:compile
org.hibernate:hibernate:3.1.3:compile
I would like to see a way for com.foo:my-artifact to suggest hibernate
3.1.1, at the same time, indicate if there is another version of
hibernate in my dependency tree (not in all of maven, just my
dependencies) which has a higher version defined, use it instead
(org.hibernate:hibernate:3.1.3 in this case). Currently, the closest
I can get to this is the range syntax, [3.1.1,) but as we all know,
this syntax will download the latest version of hibernate (today this
would be version 3.3.1.ga).
I agree that developers should be responsible for managing their
dependencies, at the same time, Maven should make things easier not
more difficult. If I have 150 dependencies, how much time should I
spend determining which artifacts should be included? Perhaps as much
time as needed; however, If there was a way to indicate use the
highest declared version of a common dependency then Maven would be
assisting me in managing my dependencies.
Does it seem like a bad idea to have a syntax that lets the highest
dependency version within my project dependency graph win, IFF I had a
way to indicate this preference?
Thanks
Chris
On Dec 9, 2008, at 12:25 AM, Jörg Schaible wrote:
Hi Ian,
Ian Robertson wrote at Montag, 8. Dezember 2008 20:35:
On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote:
[snip]
I think the short answer is, if you want repeatable builds then
don't
use range syntax.
By defining a range you are saying that everything that fits in this
range is a valid choice.
Even those in the future that have yet to be release, as long as
they
fit in the range.
Given that these future versions dont exist they haven't been tested
so using a range can be dangerous.
You raise a good point - open-ended version ranges leave one
vulnerable
to backwards-incompatible library upgrades. But the current
strategy of
taking the highest version introduces an additional element of
instability to application that can appear from one day to the next
without any change to an applications code base.
Unfortunately, without a notion of version ranges, managing versions
becomes prohibitive in projects with large dependency graphs. If an
application has several different transitive dependencies on a
particular library, the application developer is forced to traverse
the
entire graph, examine all the dependencies, and choose the highest of
them so that she is guaranteed not to hit NoClassDefFoundErrors or
NoSuchMethodErrors at runtime. For projects with hundreds of
transitive
dependencies, this is error-prone at best. Version ranges allow each
module to declare the minimum version it needs to run properly, and
let
maven do the work of finding a version acceptable to all modules in
the
dependency graph.
Nothing can really keep you save from such incompatibilities and
problems
anyway. You silently imply that a higher version is always
compatible, but
that's also not true (you know). In really worse cases it is like the
incompatible ASM 1.x, 2.x and 3.x series, but even for such an
innocent
upgrade from JUnit 3.8.1 to 3.8.2 you might get a surprise, because
the
latter uses a method not available in JDK 1.3 runtime. And this does
not
cover cases where the groupId for the artifact changes (e.g.
xstream:xstream:1.1.3 com.thoughtworks.xstream:xstream:1.2) or
artifacts
are splitted and/or renamed (e.g. avalon:avalon-framwork:4.1.4 to
org.apache.avalon:framework-api:4.3.1 and
org.apache.avalon:framework-impl:4.3.1) or two artifacts deliver the
same
classes (commons-logging:commons-logging:1.1.1 and
org.slf4j:slf4j-jcl:1.5.6) or a jar is consumed by a different one
(e.g.
org.ajax4jsf:ajax4jsf:1.1.0 into org.richfaces:richfaces:3.1.0) or
consumed
even by the JDK (javax.activation:activation:1.0.2 in JDK 6).
Therefore it is always the developers task to take care of the
complete
dependency tree of a product/project.
[snip]
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
