Indeed, the functionality is a subset of the support for version ranges, as documented at http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
(It's the 'hard requirement' syntax) This isn't just a Maven feature - Ivy has the same functionality with a different syntax - http://ant.apache.org/ivy/history/trunk/settings/version-matchers.html It just so happens that for this particular area, the syntax is the same. Maven's "soft requirements" never conflict - the highest one wins, similar to Gradle. Version ranges restrict the set of valid matches, thus setting up the possibility for conflict. So in the example of one dependency with a range of [1.0, 2.0], and another dependency with a 'soft range' of 3.0, then you end up using version 2.0. However, if the second dependency was [2.1, 3.0], then you get a conflict and the build fails. (Ivy works the same way) -- "Software is too expensive to build cheaply" Robert Watkins twitter: @twasink http://twasink.net/ [email protected] On 13/12/2011, at 2:33 AM, Daz DeBoer wrote: > OK so "pinned versions" are a built-in feature of Maven? I can't seem to find > them documented anywhere. > I assume that dependency resolution fails if you have incompatible pinned > versions in different dependencies? > Is "pinning" just a narrower case of version ranges: as in does maven fail if > one dependency declares [1.0,2.0) and another declares "3.0"? > > Actually I think I just answered my questions: > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > If there are any better docs on this I love the input. > > In the past we've relied heavily on ivy's maven compatibility layer for all > of our maven integration. As we gradually replace this code with our own > implementations, we can start to address any of the missing features. > Daz
