It would be nice if there was a configurable dependency conflict resolution strategy which followed the semantic versioning rules as described in http://semver.org.
Basically, I want to be able to tell Gradle to be ok with either minor or patch version conflicts and choose the most recent, potentially with some build output to let me know this is happening. Major version conflicts should probably result in a build failure.
What is the difference between this and existing maven dynamic version syntax like ā[1.0,2.0)ā or ivy style like 1.0.+ ?
I think Doug is referring to conflict resolution, not dependency resolution.
Weāve been looking at this issue during an evaluation we are doing of Gradle.
Currently, in the latest version it is only possible to detect a conflict and fail if this is the case.
Through manual work, it is possible to force gradle to pick a different version, potentially then resolving that or those conflicts.
However, the reporting that comes out from Gradle isnāt great at the moment. It will tell you that there is a component that is being selected in a conflicting way, but it will not tell you what the consumers of those dependencies are. To find that out you have to switch off the resolution fail strategy and consult the dependency tree.
Now, from what we have been able to summarise while looking at this issue, it appears that Gradle originally came with the Ivy stuff doing the resolving. In Ivy you have several resolution strategies, one of which is ālatest compatibleā. At some point Gradle developers appear to have removed the Ivy stuff to implement their own resolvers, and the latest compatible resolver isnāt there. Whether there is a plan to implement it is unknown to us, but we would be interested in that.
Soā¦if you use Gradle today, you have to write your own plugin to interface with the Ivy resolvers (which are builtin to Gradle but not used) and through that you can actually use the latest compatible version strategy and through such a plugin you can then resolve the dependency tree such that if there is a latest compatible version tree that can be selected that it is then selected.
Weāve done such a thing but it is not something that runs all the time. Rather you run it when the builtin resolver detects a conflict and then you have to resolve it manually using Ivy.
It would be nice if the Gradle development team could elaborate on what the strategy ahead is.
We definitely want to add fully customizable conflict resolution strategies. Plus perhaps a few conventions on top of that to solve some major use cases. However, it hasnāt topped the priority queue, yet. Thereās already a jira ticket for it.
Is there any update on that issue?
This is what weāre moving to use: https://github.com/ajoberstar/gradle-git/wiki