[GRADLE-2214] Some dependencies are reported unresolved although they are present in the cache Created: 05/Apr/12 Updated: 10/Feb/17 Resolved: 10/Feb/17
Some dependencies are reported unresolved although they are present in the Gradle cache. If using "--refresh dependencies", the dependencies are resolved, although they are not fetched from the repository (Atrifactory) as can be seen by looking at the file date.
If the command is reissued without "--refresh dependencies", it fails again. this does not concern all dependencies, only some of them
Using version 1.0-milestone-8 produces the same result, but for fewer dependencies.
This has began suddenly, and does not happen on all our computers. It happens sometimes, and sometimes, deleting the cache solves the problem, sometimes not.
Using "--refresh dependencies" could be a workaround although not for us because we are using Eclipse Gradle import, with no possibility to use parameters.
|Comment by Pierre-Yves Saumont [ 06/Apr/12 ]|
After some experiments, it appears that the problem occurs with version milestone 8, milestone 9 and RC1, but the missing dependencies are not the same.
Starting with a clean configuration, all is fine if using command line. Trying to import in Eclipse (using STS), some dependencies are reported missing although they are present in the cache.
After this, using the command lien reports the same dependencies missing. using --refresh dependencies solves the problem, until project are imported again (or refreshed) in Eclipse, which make the dependencies to be reported missing again.
It seems there are two different problems: 1) some dependencies wrongly reported as missing by the Eclipse import and 2) The information saying that the dependencies are missing seems to be cached by Gradle.
Import into Eclipse is done without checking "Dependency management", and we are using resolutionStrategy.cacheDynamicVersionsFor 0, 'seconds' and resolutionStrategy.cacheChangingModulesFor 0, 'seconds'.
Other users running version milestone 8 does not have the problem. Some have the problem and are able to fix it by clearing the Gradle cache. In some cases clearing the Gradle cache does not solve the problem.
|Comment by Adam Murdoch [ 06/May/12 ]|
When you get a machine into the broken state, can you run:
and send in the resulting logs?
|Comment by Ranga [ 16/Oct/13 ]|
Is there a fix for this yet. The issue still exists.
I am using gradle 1.4
|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:
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.