On Tue, Nov 13, 2012 at 10:49 AM, Luke Daley <luke.da...@gradleware.com>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. > I'm not sure. Changing module is rather a special case but represents a different concept from a domain perspective. Most people will never use it (once we get snapshots to 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? > It is a deprecated concept in Maven land. Not sure if Maven 3 still supports this. You could use Gradle native resolvers to deal with it in case you need to. > > 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. > I also think exposing the timestamp is a much better way in general for snapshots. But it is really changing the behavior. Which is the behavior people are used from Maven. Their are for example quite a few people checking in their .classpath files into version control to shared it with others. That wouldn't work anymore as good (if you want to use the term good in this context) if -SNAPSHOT is replaced with -[TIMESTAMP]. This is just an example. I'm concerned that there are more use cases we are not aware of. I'm not saying we shouldn't do it, but we should try to learn more about it and ask what the community thinks. > > 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. > That sounds like a good idea. > > 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. foo.jar does not have a version ;) but might be a changing module. I don't think it is necessary to try to bring those together. The major use cases are to be found in the dynamic version area anyway. So you don't run into the concept of changing modules if you don't need it. Hans > 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 > > >
