On 31 March 2012 18:02, Adam Murdoch <[email protected]> wrote:
> > On 01/04/2012, at 2:07 AM, Daz DeBoer wrote: > > On 31 March 2012 02:15, Luke Daley <[email protected]> wrote: > > There are two things I still four things I want to do before wrapping this >> up: >> >> * treat 403 and 405 HEAD requests as "metadata unknown" >> * if the server is googlecode, treat 404 HEAD requests as "metadata >> unknown" >> * when reusing a locally found resource, store the real metadata in the >> index. >> * where it's safe to, extract the sha1 from the etag (e.g. Artifactory). >> >> All of this things are small. >> > > Cool. One more thing we should do soon (but post 1.0) is allow caching of > 'file' repositories. The recent change to FileSystemResolver means that > we've removed the previous workaround for people with slow filesystem > access (eg network shares). > > I think the solution we discussed was to always cache local repository > artifacts (more consistent), but to always treat them as 'changing'. > > Thinking about this a little more, it feels a bit awkward that the exact > same artefact would be considered 'can never change' when it's up on a > remote repository, and 'can change at any time' when it's on a local > repository. > > I think what we're trying to say here that any artefact at all can change, > and that it's 'expensive' to check for changes to remote artefacts and > 'cheap' to check for changes to local artefacts. And that different > artefacts have different likelihoods that they can change, where changing > artefacts are 'likely' to have changed, and non-changing artefacts are > 'unlikely' to have changed. Whether or not we check is a function of > (how-long-since-we-last-checked, likelihood-of-change, > cost-of-checking-for-change). > You're right. I was oversimplifying. I guess another way to look at it is that we make all repositories cache-capable, and we move the logic for controlling cache timeouts into the ResolutionStrategy. This logic can be simple to start with (eg LocalRepo == refresh per build), but could be made more sophisticated in time. This will further drive our cache-control DSL and convenience methods. > I think we want to introduce a new 'cacheModulesFor' expiry period that > applies to all modules, changing or otherwise. Default this to a 'long' > period (possibly infinite) for remote repositories and a 'short' period > (possibly 0) for local repositories. Default 'cacheChangingModulesFor' to 0 > for local repositories. Such a setting would be useful, for example, for > those who want to validate all dependencies during a CI build. > Sounds like a sensible convenience method for the low-level DSL. > Over time, we will add a richer model for the lifecycle of a module, so we > can distinguish between things like: > * Something I'm working on, which needs to be checked (and maybe even > built) on each resolve. > * An active development stream, which needs to be checked frequently, > possibly on every resolve. > * A nightly or periodic build, which only needed to be checked once a day > or so. > * A release, which never needs to be checked. It is an error if such an > artefact ever changes. > Once these are part of our domain model, it will be easy to create custom cache expiry policies based on them. > That is, on every resolve we would check if the cached artifact was > up-to-date, by comparing modification-date+size, sha1, etc. > > We should do the check once per build, rather than once per resolve. It's > not a good thing to change an artefact halfway through a build, I think. > Yes, this is what I meant. Checking more than once per build may be useful when we start to expand our model to encompass release management, but currently it's not a sensible default. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
