Tell gradle not to cache snapshot dependencies (cacheChangingModulesFor 0 doesn't work as expected)

Hi gradle team and users,

I’m running Gradle 3.0 with JFrog Artifactory. I use the ArtifactoryPlugin and DependencyManagement plugin, as well as eclipse, java and maven-publish.

I have a problem with the caching of snapshot (changing module) dependencies.
Although I have set the following, snapshots are NOT updated on every build:

configurations.all {
    resolutionStrategy {
        cacheChangingModulesFor 0, 'seconds'

with this dependency:
compile ('mygroup:lib:1.0.0-SNAPSHOT') { changing = true }
(I know { changing = true } is redundant since implied by -SNAPSHOT, but I put it anyway. It shouldn’t make a difference here.)

The following happens:
1.) Deploy lib.jar-1.0.0-20160922.060203-1.jar to Artifactory
2.) gradle build => downloads lib.jar-1.0.0-20160922.060203-1.jar
<== good so far.
3.) Deploy lib.jar-1.0.0-20160922.060203-2.jar to Artifactory (xxx-1.jar still exists in Artifactory)
4.) gradle build => downloads lib.jar-1.0.0-20160922.060203-1.jar
<== This is wrong in my opinion. Gradle still sticks with the outdated version. Why?
5.) Artifactory cleans itself, so that only the newest SNAPSHOT (xxx-2.jar) exists (xxx-1.jar does not exist in Artifactory anymore).
6.) gradle build => tries to download lib.jar-1.0.0-20160922.060203-1.jar and FAILS
<== This is the same problem with worst case result (=build fails).
7.) Now I delete “~.gradle\caches\modules-2\metadata-2.17\descriptors\mygroup\jar\1.0.0-SNAPSHOT” manually. Which means, I delete the metadata for the “xxx-1.jar”.
8.) gradle build => downloads lib.jar-1.0.0-20160922.060203-2.jar
<== It seems that the jar itself is not cached (as expected), but the metadata (~pom) is cached (not expected, leads to error). Is this a bug, or am I doing something wrong here?

PS: gradle build --refresh-dependencies is working as expected and downloads the new and up2date “-2.jar”.
<== why does this work as expected and the cacheChangingModulesFor 0, 'seconds' does not?


Did you try the caching option for dynamic modules? I’m not certain, but I think snapshots might not fall into the changing modules category.

Hi Chris,
thanks for the reply!
The Gradle User Guide states the following:

An example of this type of changing module is a Maven SNAPSHOT module, which always points at the latest artifact published.

So SNAPSHOTs are changing modules and the above usage should be fine in my opinion.
Besides that, I did try the same for dynamic versions cacheDynamicVersionsFor 0, 'seconds' which didn’t do anything with the snapshots.

I have to say, I am a bit disappointed by the number of replies in this forum compared to other far less popular tools communities. Can I do anything about this? Did I post this issue in the wrong place or something?

I am experiencing the same issue. The only thing that helps is a forced command line --refresh-dependencies which is unfortunate.

@ibesenfelder, @Chris_Dore I’m facing the exact same issue with Gradle 4.2. Has there been any progress since Sep '16? Could it be resolved?

1 Like

Yes, I am having similar problems with 4.3.1, gradle will not pull the latest snapshot regardless if I set the caching strategy.

I figured out my issue! I have a multi-project build, and I didn’t have the ‘configurations.all{ … }’ block in my allprojects block. I added it there, and voila, latest snapshot downloaded on gradle-> refresh

Hi Guys,

In continuation to this thread, does

configurations.all {
resolutionStrategy {
cacheChangingModulesFor 0, ‘seconds’

brings the latest snapshots of transitive dependencies also. I don’t think it does that. Any clue on how to bring the transitive dependencies latest snapshots as well? We have lot of individual projects and putting this caching strategy doesnt seem a viable option.

Piyush Goyal

Still not fixed in Gradle 5.5.1 - the same issue

It’s been 4 years and this is still not fixed?

It’s been 6 years and this is still not fixed… Version 7.3 and same issue…

If you’re having a problem with snapshot dependencies being cached, I would recommend that you provide a concrete example of this not working where you think it should. In dozens of concrete examples, I’ve yet to see a case where if it didn’t work, it wasn’t an easily correctable user error.