On 19/12/2012, at 4:19 PM, Daz DeBoer wrote: > On 18 December 2012 12:28, Adam Murdoch <[email protected]> wrote: >> >> On 19/12/2012, at 3:57 AM, Daz DeBoer wrote: >> >> G'day >> There's been a bit of discussion about what is the best name for what >> is currently referred to as "Dependency Resolve Actions". >> Docs for this new feature are at >> http://gradle.org/docs/nightly/userguide/dependency_management.html#sec:dependency_resolution. >> >> One suggestion (mine) is "Dependency Resolve Hooks", since this is a >> way for you to hook into the dependency resolution process. >> >> >> My suggestion is 'dependency resolve rules'. >> >> >> Something else to bear in mind: we currently have a very green >> (incomplete) DSL for controlling the use of cached entries in >> dependency resolution. This DSL allows one to implement rules like >> "never use a cached entry for modules matching org.gradle.*". There >> are a lot of synergies with this DSL and the new 'Dependency Resolve >> Actions' DSL. >> >> >> I haven't forgotten about this DSL, and we talked briefly about growing the >> cache control rules so they can do substitution. We decided to keep them >> separate, so that the resolve rules are invoked early in the resolve of >> (selector -> id) and the cache control rules are invoked later, once we've >> decided what we're actually going to look for in the repositories. This way, >> the rules can concern themselves with a single aspect, and we don't need to >> worry about ordering problems between them. >> >> So, it's the same pattern, different instance. > > There is a cache-control rule that applies to the VersionSelector -> > Version caching. (Which should probably be VersionSelector -> > VersionList caching). > And there is likely a DependencyResolve rule for choosing from the > list of available versions. So I'm not sure that there is a clear > separation…
They are quite different things at the moment. A dependency resolve rule is invoked just prior to us resolving a version selector and is given the opportunity to substitute a different selector. This happens before we hit any repository or check what we have cached. A cache control rule is invoked just prior to us resolving a version selector against a repository. This happens per repository and after we have figured out what we have cached. In other words, the dependency resolve rule is concerned with the 'what' and a cache control rule is concerned with the 'where'. I think for most rules, this separation is just fine. I can't really think of a use case where the answer to 'what' changes based on what we have cached already. I can see a case for a rule to change the 'what' based on what the default answer to the question is, but I think a better solution to this problem is to provide a way for the rule to proceed with the resolution and mutate the answer, rather than exposing the cache to the rules (the cache is involved in the resolution anyway). There is a use case that looks very similar, and that is where whatever logic the rule implements is expensive to execute (e.g. it needs to hit some remote resource). We might solve this by caching the execution of the rule. That is, when selector A went into this rule 30 minutes ago, selector B came out. Reuse selector B if we're offline or the 'check for changes' setting is > 30 minutes. Don't reuse selector B if --refresh-dependencies or if the implementation of the rule has changed. For the moment, I want to keep things very simple and wait for real use cases to come along. We'll either add declarative stuff for these use cases, or we'll grow out the dependency resolve rules or cache control rules accordingly. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
