The default in Maven 2.0 is to use "soft versions", ie if you say "2.0.2", you are recommending, but not enforcing, that version.
You can instead give a range such as [1.0,2.0) - this is a hard requirement. To force a specific version, you can say [2.0.2,2.0.2]. If two dependencies have mutually exclusive ranges, the resolution fails with an error. Once all ranges are taken into account, the conflict resolver comes into play. In Maven 2.0, the only resolver is "nearest" - so the soft version in the pom nearest in the graph is used. If there is no soft version in any of the dependencies (ie, they are all ranges), the newest (ie, highest upper bound) is used. In Maven 2.1, we plan to add new conflict resolvers. This only missed 2.0 by the narrowest of margins - which was a shame as it is almost there and "newest" resolution was in fact the default in an earlier alpha but caused much confusion. So other resolvers would be to use the newest, oldest, nearest (like now), or just fail if there is more than one recommendation. While the documentation is still pending, there is a design document on docs.codehaus.org that explains the range syntax. Hope this helps, Brett On 11/9/05, Roger Hoover <[EMAIL PROTECTED]> wrote: > My understanding is that Maven 2 supports a syntax for specifying a range of > versions in a dependency. What is the syntax for this? I searched the Maven > site and found only a link saying documentation was needed for it ( > http://maven.apache.org/maven2/docs-required.html). > > Will transitive dependencies with incompatible version ranges resolve > successfully or cause an error? I assume an error would result as expected > in the following scenario where A depends on both B and C, which have > incompatible range dependencies on D. > > A -> B -> (D > 3.0) > -> C -> (D < 2.0) > > Correct me if I'm wrong in my assumptions about how Maven 2 works. My > understanding is based off of reading this thread. If I understand correctly > then I find the dependency resolution strategy unintuitive for the following > reasons: > > 1) The non-range dependency syntax requires an explicit version to be > specified but treats it like a range when it's involved in transitive > resolution. In Fabrice's example, his framework POM declared an explicit > dependency on commons-lang 2.0 but Maven treated that dependency like a > range specification (the range of all versions) such that any version would > satisfy that dependency without error. Here we have an explicit version > syntax with the semantics of the range of all versions. IMO, Fabrice's > example should have caused an error b/c these explicit dependency versions > are incompatible. In general, how can you be sure that any version of a > package will do when the author of the POM specified a particular version? > > 2) If transitive resolution behaves the way you'd expect for version ranges > and gives an error in the example I gave above, then you would expect > explicit version dependencies to just be special cases of ranges (they are > range sets of size one). Therefore, you would expect an error in Fabrice's > example again b/c his framework has a range dependency on commons-lang > 2.0where the range happens to include only one version. Likewise, the > other lib > that uses commons-lang has a range dependency on 1.0.1. These are > non-overlapping ranges. > > I may be misunderstanding the current Maven 2 behavior but if not then I > think Maven needs a more intuitive syntax. There needs to be a clear way of > expressing the following statements > * A depends on any version of B > * A depends on this specific version of B and only this version (B == 1.1.4) > * A depends on this range of versions of B (say B >= 1.0 && B < 2.0) > > Thanks in advance for any feedback. > > Roger > > On 11/8/05, Mark Hobson <[EMAIL PROTECTED]> wrote: > > > > Hi Fabrice, > > > > On 08/11/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > wrote: > > > Hi Mark, > > > > > > Thank you for your answer! :) > > > > No probs. > > > > > Then I have another question: when 2 different dependency versions are > > at > > > the same level in the dependency tree, which one wins? Because in my > > case, > > > I have version 2.0 and version 1.0.1 of commons-lang at the same level, > > and > > > 1.0.1 wins. > > > > Not sure, I know I have had problems with this before. I currently > > fix these uncertainties with an overriding dependency version in my > > top-level pom, but agree that's nasty. Have a look through the > > DefaultArtifactCollector code (see the link in my previous reply) and > > see if you can deduce what it does. > > > > > The highest-win strategy would be interesting, I agree. > > > > I would like to look into implementing this before 2.1 if I can find > > the time (probably not then ;). > > > > Cheers, > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
