On 12 December 2011 23:04, Robert Watkins <[email protected]> wrote:
> *sigh* As it turns out, I was a little premature with my description of > Ivy's resolution. > > Ivy, unlike Maven, by default does not pass the revision constraint down > the graph - all it passes is the result. So while it is good at resolving a > determined conflict, it doesn't prevent future clashes. > > (Gradle, by contrast, doesn't pass down the result yet at all) > > So the solution for both Ivy and Gradle would be to use custom conflict > managers. Now, at this stage, there is no support for customer conflict > managers in Gradle, from what I can see - is that correct? > One fundamental difference seems to be that Maven passes the full set of matching revisions for a version range into a single conflict resolution stage. Gradle (and in my understanding Ivy) resolve dynamic revisions (version ranges) independently of the entire dependency graph, only passing the 'latest' matching revision up for comparison in the conflict resolution stage. Now that our implementation of dependency resolution (and conflict resolution) is relatively independent of ivy, we may be able to improve the algorithm to be more maven-like in this manner. This code is relatively new and is still being actively improved: check out org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultDependencyResolver if you want to check this out in more detail. Thanks for the input. Daz
