On 21/10/2012, at 11:39 PM, Adam Murdoch wrote: > Hi, > > I'd like to make a change to how we resolve dynamic versions, in particular > when a module is published without a meta-data file. This would be a breaking > change. > > Currently, to resolve a dynamic version for a given repository: > > 1. For each meta-data pattern: > 1. List versions that match this pattern (using maven-metadata.xml or a > directory listing). > 2. Order the versions from highest to lowest. > 3. For each version that matches the version selector, check for the > meta-data file. If it exists, use this version. > 2. For each artefact referenced in the dependency (usually just a jar): > 1. For each artefact pattern: > 1. List versions that match this pattern (using > maven-metadata.xml or a directory listing). > 2. Order the versions from highest to lowest. > 3. For each version that matches the version selector, check > for the artefact. If it exists, use this version. > > There are a few issues with this: > > 1. If a meta-data file is not published for a module, then we scan all of the > versions looking for the meta-data file before starting the scan again > looking for the artefacts. For a 'latest.$status' version, this means > scanning all of the versions that have ever been published. > > 2. If a module switches from publishing to not publishing a meta-data file, > then the algorithm above will lock on to the highest version with a meta-data > file and ignore any later versions without a meta-data file. > > 3. For most repository layouts, we end up listing the same directory multiple > times, when meta-data files are not published. > > Things get more complex when you add in multiple repositories, as we iterate > over the repositories applying the matching above and then choose the highest > version found from each repository, regardless of whether it has meta-data or > not. > > I'd like to split the matching into 2 discrete stages: firstly, determine all > the potential versions without verifying that they exist, then scan this list > looking for the first version that exists. Specifically: > > 1. Calculate the set of candidate versions > 1. For each meta-data pattern, if we've not seen this pattern yet, list > versions that match this pattern. Add to the set of candidates. > 2. For each artefact pattern, if we've not seen this pattern yet, list > versions that match this pattern. Add to the set of candidates. > 2. For each candidate version from highest to lowest > 1. If this version does not match the version selector, skip. > 2. For each meta-data pattern, check for the meta-data file. If it > exists: > 1. Download and parse the meta-data. > 2. If the version selector does not accept the meta-data, skip. > Otherwise, use this version. > 3. Use default meta-data for this version. If the version selector does > not accept the meta-data, skip. > 3. For each referenced artefact > 1. For each artefact pattern, check for the artefact. If it > exists, use this version. > > This addresses the above issues. It is also a step towards the overall > structure that we want for the dependency resolution algorithm, where as we > traverse dependencies in the graph, we resolve first to a set of candidate > versions and later narrow this down to a single version as we traverse the > graph and apply conflict resolution. > > The downside of this change is that it will break a build that relies on the > behaviour for issue #2 above. That is, a build that: > > 1. Consumes a module that has switched from publishing meta-data files to not > publishing meta-data files, and > 2. Expects that resolving adds an implicit 'and has a meta-data file' to the > version selector. > > The workaround for these builds is to replace the dynamic version with either > a version range or a specific version, either in the dependency declarations > or via a forced version. > > Given this, I think this is a reasonable breaking change to make.
Seems like a reasonable, justified breaking change to me. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
