Internals of artifact cache timeouts

[Chris Doré]

Hi folks,

Cache timeouts can be configured via cacheDynamicVersionFor. I'm interested in learning more about how this is implemented, specifically what state information is being used (and where it's stored; local project cache? global cache?) in order to determine when a dynamic version needs to be re-resolved.

If someone knows the immediate answer that would be great, but if anyone has some pointers into the source tree it would be equally appreciated.

Speculation about the implementation details that drive the cache expiry came up during a debate with some colleagues, so we're just curious about digging a little deeper for our own education.

Thanks, Chris

[Adam Murdoch]

On 12 Mar 2014, at 8:35 am, Chris Doré <[hidden email]> wrote:

Hi folks,

Cache timeouts can be configured via cacheDynamicVersionFor. I'm interested in learning more about how this is implemented, specifically what state information is being used (and where it's stored; local project cache? global cache?) in order to determine when a dynamic version needs to be re-resolved.

For dynamic versions, Gradle does the caching per repository, and the only real state it considers is how long since it last checked for versions that match the dynamic version in the repository. If that time is greater than the value specified for `cacheDynamicVersionsFor` then Gradle goes and checks the versions again.

The `—refresh-dependencies` and `—offline` command-line options override this.

In Gradle 1.12, this algorithm will change slightly, so that Gradle will check not per dynamic version but instead per module. What this means is that, previously, if I had both “mylib:mylib:1.2+” and “mylib:mylib:latest.integration” declared as dependencies, then Gradle would check the versions once for “mylib:mylib:1.2+” and again for “mylib:mylib:latest.integration”. Instead it will now check the versions once for “mylib:mylib” and reuse that result for both dynamic version selectors.

The state is stored under ~/.gradle/caches/modules-2/metadata-2.n, so it’s global to the machine.

If you want to dig into the code, CachingModuleVersionRepository takes care of the decision of what to use from the cache and when.

--

Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

[Chris Doré]

Thanks Adam, very useful info!

Chris

On Wed, Mar 12, 2014 at 1:04 PM, Adam Murdoch <[hidden email]> wrote:

On 12 Mar 2014, at 8:35 am, Chris Doré <[hidden email]> wrote:

Hi folks,

Cache timeouts can be configured via cacheDynamicVersionFor. I'm interested in learning more about how this is implemented, specifically what state information is being used (and where it's stored; local project cache? global cache?) in order to determine when a dynamic version needs to be re-resolved.

For dynamic versions, Gradle does the caching per repository, and the only real state it considers is how long since it last checked for versions that match the dynamic version in the repository. If that time is greater than the value specified for `cacheDynamicVersionsFor` then Gradle goes and checks the versions again.

The `—refresh-dependencies` and `—offline` command-line options override this.

In Gradle 1.12, this algorithm will change slightly, so that Gradle will check not per dynamic version but instead per module. What this means is that, previously, if I had both “mylib:mylib:1.2+” and “mylib:mylib:latest.integration” declared as dependencies, then Gradle would check the versions once for “mylib:mylib:1.2+” and again for “mylib:mylib:latest.integration”. Instead it will now check the versions once for “mylib:mylib” and reuse that result for both dynamic version selectors.

The state is stored under ~/.gradle/caches/modules-2/metadata-2.n, so it’s global to the machine.

If you want to dig into the code, CachingModuleVersionRepository takes care of the decision of what to use from the cache and when.

--

Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com