[GRADLE-1103] Gradle cannot resolve unique SNAPSHOT artifacts from local m2 repo Created: 10/Aug/10  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: None

Type: Bug
Reporter: Russ Rollins Assignee: Unassigned
Resolution: Won't Fix Votes: 3


There appears to be an issue in consistently retrieving SNAPSHOT artifacts from a local m2 repository. What I've observed is:
1. Gradle Project x installs its artifact, projx-1.0-SNAPSHOT.jar into local m2 repo
2. md5s correctly match on both the built jar and the one installed via the task
3. Gradle Project y, which depends on projx-1.0-SNAPSHOT.jar, should retrieve projx-1.0-SNAPSHOT.jar and place it into the Gradle cache
4. but md5s do not match in Gradle cache compared to m2 repo and the Project x local artifact

I was able to repeatedly demonstrate this behavior in my local development environment over the course of 30 minutes. Current workaround is to manually remove projx-1.0-SNAPSHOT.jar from the Gradle cache when building Project y to ensure that the cache is properly updated.

Comment by Hans Dockter [ 15/Aug/10 ]

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.

Comment by John Gibson [ 21/Nov/10 ]

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


Comment by Daz DeBoer [ 14/Nov/11 ]

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).

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:

  • 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!

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.

Generated at Wed Jun 30 11:46:58 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.