I have an intermittent problem that seems to be related to inconsistencies in the Gradle cache. Are there any tools for checking the Gradle cache for inconsistencies?
In particular, it appears that the ~/.gradle/caches/modules-2/metadata-2.97/module-artifact.bin has a reference to a file ~/.gradle/caches/modules-2/files-2.1/edu.vu.isis.foo/bar/2022.1.1/23f8b6cd18644da7a1e23a7049e6b463/bar-2022.1.1.zip which is, in fact, not present.
This inconsistency is not subsequently rectified by acquiring this missing artifact and the build fails.
I believe this is a pair of Gradle bugs.
There is a condition where the metadata and the files get into an inconsistent state.
The inconsistent state is not corrected in subsequent runs.
It seems the following corrects defects in the dependency graph.
./gradlew --refresh-dependencies :depencencies
" At times, the Gradle Dependency Cache can become out of sync with the actual state of the configured repositories. Perhaps a repository was initially misconfigured, or perhaps a “non-changing” module was published incorrectly. To refresh all dependencies in the dependency cache, use the --refresh-dependencies option on the command line." – Handling versions which change over time
The :dependencies task is not strictly necessary but it should force a download of dependency metadata.
Be aware, that only refreshes the dependencies actually resolved.
So if any other state is out of sync that is only used in a different project, it is not touched.
And if some dependency is only resolved at execution time of a task, for example using a detached configuration, it will not be refreshed by calling dependencies with that switch.
Alternatively you could also just delete the whole cache files and Gradle will redownload things when they are needed.
Yes, I understand that.
I posted the running of ./gradlew --refresh-dependencies :depencencies as a solution, that is only partly true.
The corruption occurs fairly regularly, though not often enough to post a reasonable bug report.
I suspect the problem is due to how a failed metadata, via *.pom, request is handled.
That is, it seems that when the metadata via pom fails the artifact is presumed to be a *.jar.
Generally, this is a fine assumption but in my case the artifact is a *.zip.
That metadata gets added to the cached metadata.
Subsequently, when the *.pom becomes accessible it is too late as the cached metadata is already wrong.
