[GRADLE-2257] Gradle doesn't see latest installed Maven snapshot Created: 26/Apr/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-rc-1
Fix Version/s: None

Type: Bug
Reporter: Ryan Stewart Assignee: Unassigned
Resolution: Won't Fix Votes: 5


If I install a SNAPSHOT version of a Maven project with "mvn install", then tell gradle to "--refresh-dependencies", it still pulls the latest snapshot from a remote repo instead of the fresh one from my local repo. Presently, I have three repositories set up in my build file. The first two are remote (Nexus) repos, and the third is my local Maven repo. It seems I have to deploy the new snapshot to the remote in order for gradle to pick it up as "latest". I'm wondering if maybe it's because deployed snapshots get a timestamp, but an installed one is just "xxx-SNAPSHOT"?

Comment by Szczepan Faber [ 30/Apr/12 ]

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!

Comment by Ryan Stewart [ 03/May/12 ]

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.

Comment by Kevin Stembridge [ 15/Sep/12 ]

This issue is very similar to a problem I raised on the forums.

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.

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 12:17:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.