The way Gradle's dependency resolution works is: we look for the dependency in the repositories(resolvers) in the order the repositories have been declared. When we find a match in repository X we no longer search in repositories X+1.

So, gradle found your snapshot in the first repo and didn't look in other repos regardless if they contain a newer snapshot or not.

There are good reasons why Gradle works like that. Performance is one of them.

If you are very keen on searching across all repositories there's no clean workaround at the moment. In your case, I suggest to make the local repo the first repository on the list. If this is not a viable solution for you I'm keen on understanding your use case better.

Hope that helps!

I see. It seems we misunderstood the dependency resolution as presented in "How dependency resolution works". It sounded like SNAPSHOTs would be resolved to the latest version in any repo, but upon further investigation, we found that "Dynamic Versions and Changing Modules" defines the terms used in "How dependency resolution works" such that SNAPSHOTs aren't included.

We were planning to use this as a workaround for another bug (which I found has already been reported), but I guess we'll have to figure out something else.

This issue is very similar to a problem I raised on the forums.
http://forums.gradle.org/gradle/topics/maven_snapshots_are_not_being_updated

In my case, I'm building with Gradle and publishing to a local Maven repo but the use case is the same. We need to be able to make changes to multiple projects locally and test them before committing them to source control or deploying them to a remote repo. Gradle is not capable of publishing to its own local cache (see GRADLE-1615) which is why I'm publishing to a local Maven repo.

I think its fine for Gradle to stop at the first repository once it finds the right snapshot version. Its very unlikely that snapshots would exist in more than one repository. But in order to achieve the workflow described above and in GRADLE-1615 it must be possible to publish to the local Gradle cache.

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.