Hi,
If jars files are modified in the gradle cache (by some external process or person), we noticed that the --refresh-dependencies flag does not actually actually refresh the artifacts. Is this a bug or is it by design?
Example: After running a build, I go modify a JAR file inside the gradle cache such that the sha1 hash no longer matches the hash in the directory structure:
.gradle/caches/modules-2/files-2.1/ … /48aega55aac7b065gba4kpe85B9f1dfcce6dc725/foo.jar
After this, I rerun the build with the refresh dependencies flag, but foo.jar is still the tempered one.
Context for the issue:
At LinkedIn, one of the initiatives that we are working on is creating a concept of “thin wars”. The idea is that instead of packaging all of the JAR files inside every WAR that we publish, we exclude those files that already exist in the Artifactory repository. Instead, we include a manifest inside the WAR so that we can download the correct JAR files at runtime from Artifactory. In order to ensure that we deploy with the same files that we build with, we added a sha1 hash inside the manifest.
How we ran into the issue is that on one of our build machines, a JAR file in the gradle cache was modified (some external process added some certificates to the JAR file). With this change, the JAR file now has a sha1 hash that does not match the sha1 in Artifactory.
When our project was built, the modified JAR file was used (and the manifest included the modified sha1 hash). This caused the checksum to fail during deploy when the JAR is downloaded.
We are looking for a way to ensure that we always build with what is in Artifactory (even if the local gradle cache is tempered). Perhaps this can be done by verifying that the sha-1 hash in the directory structure actually matches with the sha-1 hash of the JAR file. We would have thought --refresh-dependencies would solve this issue, but testing this locally, I still see the modified JAR file remaining. Is this a bug or is it by design?
Thanks!
Bill