Just wanted to announce some fairly significant updates to the way we are performing dependency resolution for dynamic versions.
Using component metadata rules, it's possible to update the 'status' of an ivy module during resolution. This status value is then used to determine which module version to choose when using a resolver like 'latest.release' (choose the newest version with a status of 'release').
Until now, there has been an issue with caching of these values. Since we cache the mapping of 'latest.release' to a specific version, any changes to the rules were not reflected until cache expiry. This is a problem because we think that component metadata rules should be 'live', and not have the result of these rules cached.
This issue is now fixed, but it involved some significant changes. The biggest change is that the resolver is no longer responsible for mapping a dynamic version to a single version: the resolver simply returns a list of available versions for a module, and the high-level UserResolverChain chooses the best matching version from that list. This means that each ModuleVersionRepository now has 3 functions: list versions for a module, get metadata for a module version, and get artifacts.
There are a few implications of this change:
This change greatly simplified ExternalResourceResolver, and should make it easier for us to move forward with planned improvements to make dependency resolution variant aware.
Thoughts and feedback welcome.
On 16 Feb 2014, at 2:59 pm, Daz DeBoer <[hidden email]> wrote:
This is good stuff. We can also later push this up higher again, to take into account all incoming selectors when selecting a version (eg given `1.+` and `[1.2,1.5]` we should choose 1.5 even when 1.6 is available - that kind of thing).
This also means we make fewer HTTP requests when there are multiple dynamic selectors for a given module resolved during a build, and also only get the meta-data file once when resolving a dynamic selector against multiple repositories.
It also means that new versions don’t appear at arbitrary points during the build - so, for example, if I resolve `latest.integration` and determine that versions 1.1 and 1.2 are present (selecting 1.2), and then later resolve `latest.release`, I don’t suddenly have 1.3 appear.
I think we can live with this. We could possibly have the cache manager that we pass to the resolver deal with this and short-circuit downloading any meta-data file that we’ve already downloaded in the same resolve.
|Free forum by Nabble||Edit this page|