Thanks Adam, very useful info!
Chris On Wed, Mar 12, 2014 at 1:04 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote: > > 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 > > > >
