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. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
