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.

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?

This ticket is a clone of GRADLE-646 - I repeat my comment here as well, because this seems to be the main ticket

From the user guide:

If you are familiar with Maven or Ivy approach you will be delighted to learn that:

• All the concepts that you already know and like are still there and are fully supported by Gradle. [...]
• Gradle works perfectly with your existent dependency management infrastructure, be it Maven or Ivy. [...] No changes necessary.

[...]

In your dependency description you tell Gradle which version of a dependency is needed by another dependency. This frequently leads to conflicts. Different dependencies rely on different versions of another dependency. [...] What Gradle offers you is a resolution strategy, by default the newest version is used.

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.

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:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

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.