[GRADLE-1193] Make dependency resolution strategy user configurable Created: 28/Oct/10 Updated: 10/Feb/17 Resolved: 10/Feb/17
The user guide mentions at 32.2.3.
There should be a method of configuring this.
One simple alternate strategy is to fail when conflicts are encountered.
|Comment by daniel carter [ 21/Jun/11 ]|
In the meantime could someone update the documentation to state "the only resolution strategy currently is to use the newest". Implying there are alternatives is misleading and causes much time wasting trying to find the documentation for how to change it.
|Comment by Robert Watkins [ 18/Jul/11 ]|
Any update on this? This is kind of a deal breaker for me using Gradle, as one of the major drivers to get off Maven is a serious bug in the version ranges. Being able to set upper limits on versions is important.
Alternatively, is it possible to bypass the layers put on top of Ivy and just delegate all the dependency support down to that?
|Comment by Tamás Kozma [ 21/Sep/11 ]|
This ticket is a clone of
From the user guide:
Based on this, I believe everyone would assume Gradle has the same flexibility to deal with version conflicts as Ivy does. In any case, I had taken that for granted, only to find this is not the case after investing a lot of time into setting up a Gradle build environment at my company (for .NET projects, which in most aspects went fine this far). This means we cannot use Gradle as it is today, because we want to detect version conflicts early on.
I looked into the source code, and as far as I can tell, it would be very simple and straightforward to expose Ivy's default conflict resolver (and circular dependency resolver, if we are already at it) setting. I understand that you aim for something more advanced and Gradleish in the long run, but I believe letting users configure such default plugins is a very good first step, would not cross any further plans and would enable most scenarios.
What do you think? If I sent you a patch for this, would you consider it? Do you see any problems with such a simple approach? Just to reiterate: this is a dealbreaker for us, and as I have seen on forums and mail archives, for others as well.
|Comment by Benjamin Muschko [ 15/Nov/16 ]|
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]|
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.