I will have a look at this for 0.9.1. I'm on holidays right now and probably won't be able to dive into this. In general I can't wait to replace the Ivy (reverse engineering) Maven logic with native code from the Maven project (which we do already for publishing). Although Ivy does not a bad job, there are always issues.

I found some fixes for this problem. One is to flag SNAPSHOT dependencies as changing. The other is to set the checkModified property on the GradleIBiblioResolver to true. The first fix would only correct the changing dependencies that actually contain "-SNAPSHOT" in the version. This would work fine for Maven dependencies, but dynamic Ivy dependencies such as "latest.integration" may not be checked properly. The second fix could be too aggressive in checking dependencies and might check stable versions for changes.

I believe that both approaches could cause issues when using Gradle with SNAPSHOTs in a remote Maven repositories. I believe that either fix would cause every SNAPSHOT dependency to be checked against a remote repository for every build, but I haven't tested this theory.

I have no automated tests for this because I'm not sure how to properly write a test for this issue. Does the Gradle testing infrastructure have a method for actually invoking Gradle on a series of projects and handling the side effects in the local Maven repository?

If Gradle is switching to Maven Ant tasks for downloading then perhaps one of these approaches can be applied as a temporary fix.

Both approaches can be found on branches in Github: GRADLE-1103-1, GRADLE-1103-2

https://github.com/jgibson/gradle/tree/GRADLE-1103-1
https://github.com/jgibson/gradle/tree/GRADLE-1103-2

SNAPSHOT dependencies cannot be resolved out of the local m2 repo [mavenLocal()], because there is no file called 'maven-metadata.xml'. Instead, there is a 'maven-metadata-local.xml' and 'maven-metadata-remote.xml': we need to use one of these files to assist in resolving SNAPSHOTS (and dynamic versions, possibly).

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.