Repeat Timer on Gradle Cache Artifact Error

Hello Gradle People,

We have an issue with the repeat timer when an artifact version download error has been cached by gradle. The use case is the following: If I try to download an artifact that I forgot to upload on my repo, the error is cached by gradle for quite a long time, impairing the ability to see soon enough the fix of the upload.

To avoid this long timeout waiting we have found two workarounds: 1) just forget the impaired version by doing the upload/download cycle with a new version (cumbersome) 2) remove entirely the gradle cache to make it forget the error

Questions: Is there a better workaround than 1) or 2) ? Is the repeat error timer duration patchable ? What is the value by default of this timer ?

Thanks,

Jean-Pierre

Run Gradle with the ‘–refresh-dependencies’ flag to force revalidation of caches.

Is it possible to change the value of the timer ?

Thanks,

Jean-Pierre

Which Gradle version are you using? I thought this had been changed to only remember the error until the end of the build.

I am using Gradle 1.2.

Jean-Pierre

I’m not aware of a solution other than ‘–refresh-dependencies’ then. I recommend to try with the latest version.

I’m not certain what you mean by “repeat timer”, but you can control how often the cache is refreshed.

This will work for any dependency marked as “changing” in your build script. For dependencies that are not marked a “changing”, Gradle assumes that they will not change over time, so will not refresh the cache automatically. That’s why you need to use ‘–refresh-dependencies’ for these types of problems.

Are you saying that the same timeout mechanism/property is used in the event of an error (repository cannot be reached, artifact cannot be found, etc.)?

I actually missed that the issue was a “missing” module; I originally thought the problem was a bad module in cache.

If the repository cannot be reached, we wouldn’t cache anything.

For missing modules, the cache timeout is 24 hrs by default. For newer versions of Gradle this is not a problem (I think), since Gradle will try again to resolve a missing dependency before failing the build. For older versions I’m pretty sure we used the “changingModule” timeout value to control when a missing module was refreshed.

This was fixed in Gradle 1.3

Thanks for your answers and help, I guess the final answer is that I really need to schedule an upgrade in my production chain.

Jean-Pierre