On 13/11/2012, at 8:49 PM, Luke Daley wrote: > > On 13/11/2012, at 5:49 AM, Adam Murdoch wrote: > >> Hi, >> >> We have a bunch of issues queued up to fix in Gradle 1.4, all related to >> problems with using maven snapshots. For example, the source zips that the >> IDE project point to are not updated when a new snapshot is used. All of >> these are due to shortcomings in our implementation of changing modules. >> >> We have two basic approaches that we could take to fixing these: >> >> 1. Fix the issues with changing modules. >> 2. Switch to using dynamic versions for Maven snapshots. This will address >> the issues for Maven snapshots. We would then later fix the issues with >> changing modules. >> >> I'd like to go with option 2, as it is a better description of reality. It >> also allows us to make some nice performance improvements: >> * Don't download and parse maven-metadata.xml for every artefact download or >> up-to-date check. >> * Don't check if artefacts are up-to-date when maven-metadata.xml has not >> changed since last time we resolved. >> >> There are a bunch of other advantages to modelling Maven snapshots as >> dynamic versions. > > The distinction between “changing” and “dynamic” is confusing and non obvious > for users. It makes sense technically of course, but if we can unify this > concept I think we should for the sake of simplicity.
We're not talking about unifying changing modules and dynamic versions here. The distinction would stay (for now). We're just talking about switching from modelling maven snapshots as changing modules to modelling them as dynamic versions. > >> Depending on how we approach this, there are some potential breaking changes >> here: >> >> 1. The resolved version reported by the resolution result APIs will change >> from '1.0-SNAPSHOT' to something like '1.0-20120101-120000-1'. > > What about when non unique snapshots are used on the server? That would continue to be modelled as a changing module, so you'd get '1.0-SNAPSHOT'. Same for the jar name. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
