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...

-- 
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to