On 22/10/2012, at 9:39 AM, 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.
I just discovered that we actually download the artefacts in step 2 above, rather than making a head request, thanks to a logic bug. Now it gets a bit tragic. For example, say you publish your integration and milestone builds to a snapshot repository, and your releases to a release repository. When we resolve 'latest.release', we will download and parse the ivy descriptor for every version in the snapshot repository. We will then start again with the jars for every version in the snapshot repository, downloading each one. After doing all this, we will return 'not found'. After making the changes below, we'd be able to fix this, so that we would list the candidate versions from the snapshot repository, list the candidate versions from the release repository, then iterate over the union of versions from highest to lowest, looking for the first version that meets the constraints. This means we'd only scan the snapshot repository as far back as the most recent release in the release repository. This would also improve dynamic versions in general, as we'd scan each repository only as far back as the highest version from any repository. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
