On 28.09.2011, at 12:12, Luke Daley-2 [via Gradle] wrote: > > On 28/09/2011, at 5:16 AM, Adam Murdoch wrote: > >>>> >>>> * For dynamic revisions, stopping on the first resolver means we may miss >>>> a newer revision that happens to be in a later repository. An alternate >>>> approach might be to use all resolvers for dynamic revisions, but only >>>> when there is no unexpired value in the cache. We could do this search in >>>> parallel, and just pick the latest out of those we have found at the end >>>> of some timeout. Perhaps we could do the search in parallel for all >>>> revisions, dynamic or not. >>> >>> If more than one network-based resolver is likely to perform a search, >>> it makes good sense to me that those searches be in parallel. >>> >>> Once an artifact is served from a particular repository, a newer >>> version of it is commonly served by the same repository. That >>> information could be used to alter the search order - although that >>> could admittedly hurt the determinism of builds, especially if the >>> resolution strategy does not search using all resolvers. >> >> Right. I'm thinking more and more that we should search all repositories for >> dynamic revisions. Which means it doesn't really matter which order we use >> them. It's the latest strategy's job to decide which actual revision to use. > > > Wouldn't mapping dependencies to repositories make the speed/accuracy trade > off less? If we knew we only had to look in a single repository for a > dependency then some of these issues disappear.
I like the idea that one could specify, for a given dependency, from which repository to retrieve it. In those cases where I don't have all repos behind a virtual repo url, it would be very explicit that a given dependency comes from a certain repo. Just my two cents worth on this. > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > > If you reply to this email, your message will be added to the discussion > below: > http://gradle.1045684.n5.nabble.com/dependency-resolution-algorithm-tp4840257p4848611.html > To unsubscribe from Gradle, click here. -- View this message in context: http://gradle.1045684.n5.nabble.com/dependency-resolution-algorithm-tp4840257p4848788.html Sent from the gradle-dev mailing list archive at Nabble.com.
