Configuration-cache combined with --refresh dependencies

Help/Discuss
1

Hello

We unfortunately have some snapshot dependencies in our project.

dependencies {
//propriotary... is there any good constantly changing public snapshot version I can use?
    implementation("Ums.LocalizationResources.UMS-Studio:UmsStdPlugins:1.0-SNAPSHOT"){
        isChanging=true
    }
}

No we start using some target like gradlew classes, gradlew jar, gradlew app:dependencyInsight --configuration runtimeClasspath --dependency UmsStdPlugins

> Task :app:dependencyInsight
Ums.LocalizationResources.UMS-Studio:UmsStdPlugins:1.0-SNAPSHOT:20241105.111326-47

Now we want to force an update to our Snapshot depenency and use gradlew build --refresh-dependencies.
And yes looking at the output we can see that gradle now downloads a new published artifact.
However every task that has been cached by the configuration cache stays on the old version:
gradlew app:dependencyInsight --configuration runtimeClasspath --dependency UmsStdPlugins

> Task :app:dependencyInsight
Ums.LocalizationResources.UMS-Studio:UmsStdPlugins:1.0-SNAPSHOT:20241105.111326-47

and forcing it to ignore the configuration-cache “works”
app:dependencyInsight --configuration runtimeClasspath --dependency UmsStdPlugins --no-configuration-cache -Dorg.gradle.unsafe.isolated-projects=false

> Task :app:dependencyInsight
Ums.LocalizationResources.UMS-Studio:UmsStdPlugins:1.0-SNAPSHOT:20241105.113159-48

So I guess if you want to do a --refresh-depdencies you should also manually delete the configuration-cache directory? Or is there something else I am missing?

2

Sounds to me like a bug you should report if there is none yet.
The resolution result is part of the CC entry, yes.
The lifetime of the CC entry afair is the the time changing and dynamic version resolution is cached.
I guess when using --refresh-dependencies manually all CC entries should maybe be invalidated. :man_shrugging:

1 Like