On 14/11/2012, at 2:43 AM, Hans Dockter wrote: > > > > On Tue, Nov 13, 2012 at 10:49 AM, Luke Daley <[email protected]> > 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.
I would think about solving the IDE problem by copying the dependencies into $projectDir/.gradle (and using relative paths while we're there). We can use the symbolic names (1.0-SNAPSHOT) in the IDE specific store. We also have some flexibility here. We can expose the unique version (the timestamped one) or the symbolic version (the -SNAPSHOT one) independently in different places. So we might report the unique version in the resolution results but continue to use the symbolic version in file names. Or we might offer a way to resolve the files using symbolic versions, and use this in the IDE plugins instead. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
