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. > 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? > 2. The resolved file name will change from 'mylib-1.0-SNAPSHOT.jar' to > 'mylib-1.0-20120101-120000-1.jar'. > 3. The 'cacheChangingModulesFor' setting will no longer affect snapshots, as > the 'cacheDynamicVersionsFor' setting will now affect it. > > A quick note on #2: when you resolve snapshots from a local Maven repository, > you already get the file name with the timestamp in it. I'd like to seriously consider going ahead with the breaking change for #1 and #2, it's a much better behaviour. > We don't necessarily need to expose the timestamp, and instead could keep it > as an internal value. This would get rid of #1 and/or #2. I'm strongly for exposing the timestamp. > For #3, we could: > > 1. Add a default timeout for all cached information, that you can set instead > of the specific cache timeouts. eg. 'cacheFor 0, "seconds"' would check both > dynamic versions and changing modules on every resolve. > > 2. Add a specific maven-snapshot timeout, that works regardless of how maven > snapshots happen to be implemented. > > These don't avoid the breaking change, they just avoid a similar situation in > the future. I'm for deprecating changeDynamicVersions and cacheChangingVersions and introducing a new unified setting. I don't see any real value in splitting this up, and like the simplification of one “cacheable” type concept and TTL setting. This all hinges on being able to find the overarching concept that describes all cases where the requested version number is dynamic in someway and can result is different results at different times. The term “dynamic version” works for me, so I think we can just broaden this. The risk is though that this becomes confusing to Ivy people. I'm not too concerned about that though. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
