> * We're making a performance-accuracy trade-off here. Which means we'll
> probably need some way to tweak the behaviour. Not sure exactly how this
> might look, yet. I'd start with a simple time-to-live property on each
> configuration, and let the use cases drive anything beyond that.
How about a triggered build on a CI server with the triggered project
using a dynamic revision to reference the project that triggered it?
To me that's most cleanly addressed by using all resolvers for dynamic
revisions as you suggest.
> * 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.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
