SNAPSHOT dependencies are not detected without number

When consuming a dependency like this:

compile 'com.acme:server:SNAPSHOT'

then the maven-metadata.xml in the repository is not checked first in order to find the latest timestamped snapshot. Changing it to:

compile 'com.acme:server:99-SNAPSHOT'

and it works.

Because we have a continuous development process without predefined versions, SNAPSHOT always points to the trunk/head of our development. So not having the number makes sense.

Gradle considers any version with a “-SNAPSHOT” suffix a changing module. If the version is simply “SNAPSHOT” you can explicitly tell Gradle that the dependency is changing.

compile('com.acme:server:SNAPSHOT') {
    changing = true
1 Like

Thanks for that. Very helpful. Can I suggest that you add the text you wrote to the documentation. I think that’s quite important for people to know and the “changing” flag isn’t clearly documented (that I found) outside the Javadoc for gradle.

I’m still not sure if this is a bug. Should the hyphen be part of the check that this is a snapshot or just the word “SNAPSHOT”?

I believe including the hyphen is consistent with the Maven behavior so I would not consider this to be a bug.

1 Like

Unfortunately even your suggestion doesn’t work right.

compile('com.acme:server:SNAPSHOT') {
    changing = true

Does not find the resources. However with


I see it tries to load com/acme/server/88-SNAPSHOT/maven-metadata.xml and then determine the correct latest timestamped pom to grab.

I’m guessing the problem is in the MavenResolver. I guess I’ll need to make a fake version number to get this working.

There seems to be somewhat of a disconnect between the Maven deployment code and our resolution logic. You don’t necessarily have to create discrete versions for your module, you just simply can’t use the version ‘SNAPSHOT’, you’ll have to name it anything else. This in conjunction with changing = true should give you the result you’re looking for.

Well, I named it “99-SNAPSHOT” which counts as anything else. Thanks for all your help, but I still think this functionality needs to be better documented in gradle. It is all a bit ‘magic’ as to why it sometimes works.

Even the ‘changing’ flag isn’t documented to mean “will look for timestamped pom versions”. Rather, its documentation seems to suggest that the functionality is only “check for new versions often and don’t rely on the cache”.

This is correct. Timestamped versions are specific to ‘SNAPSHOT’ versions in Maven repositories. The notion of a ‘changing’ module is repository agnostic.

I’m beginning to think this might actually be an issue with Maven. The code I linked to above seems to indicate that a version of “SNAPSHOT” is not valid, however Maven is perfectly content with publishing such a module and will use the timestamp name scheme as with other snapshots. In any case I’ve raised GRADLE-3350 to track this as we should probably handle this case better.