On 12 Mar 2014, at 8:35 am, Chris Doré <oesoluti...@gmail.com> 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
