Thanks, Brett. I think this is the document you're refering to. http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
On 11/8/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > 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 <http://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] > >
