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. 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'. 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. 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. 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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
