SNAPSHOT dependencies are not detected without number

ari · October 16, 2015, 11:24am

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.

mark_vieira · October 17, 2015, 1:30am

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
}

ari · October 17, 2015, 9:28am

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”?

mark_vieira · October 17, 2015, 8:06pm

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

github.com

apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L957


    {
        return true;
    }


    addViolation( problems, severity, version, fieldName, sourceHint, "is missing.", tracker );


    return false;
}


private boolean validateBoolean( String fieldName, ModelProblemCollector problems, Severity severity,
                                 Version version, String string, String sourceHint, InputLocationTracker tracker )
{
    if ( string == null || string.length() <= 0 )
    {
        return true;
    }


    if ( "true".equalsIgnoreCase( string ) || "false".equalsIgnoreCase( string ) )
    {
        return true;
    }

ari · October 20, 2015, 1:14am

Unfortunately even your suggestion doesn’t work right.

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

Does not find the resources. However with

compile('com.acme:server:88-SNAPSHOT')

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.

mark_vieira · October 20, 2015, 7:27am

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.

ari · October 21, 2015, 10:46pm

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”.

mark_vieira · October 21, 2015, 11:15pm

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

mark_vieira · October 21, 2015, 11:18pm

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.