On 18/12/2012, at 11: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'. What's the scope of this "hook"? Is it limited to affecting what actually gets resolved? If so, “dependency resolve rule” makes perfect sense. > >> >> 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. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com >
