As a testcase (entire ‘build.gradle’ not included), I built something with a dependency on log4j 1.2.12:
dependencies {
runtime group: 'log4j', name: 'log4j', version: '1.2.12'
}
Note that while the SHA-1 checksum of this file is ‘057b8740427ee6d7b0b60792751356cad17dc0d9’ (40 characters, with leading zero), the directory that the file is placed in the cache is ‘57b8740427ee6d7b0b60792751356cad17dc0d9’ (39 characters, without leading zero):
$ sha1sum /opt/gradle/rich/.gradle/caches/modules-2/files-2.1/log4j/log4j/1.2.12/57b8740427ee6d7b0b60792751356cad17dc0d9/log4j-1.2.12.jar
057b8740427ee6d7b0b60792751356cad17dc0d9
/opt/gradle/rich/.gradle/caches/modules-2/files-2.1/log4j/log4j/1.2.12/57b8740427ee6d7b0b60792751356cad17dc0d9/log4j-1.2.12.jar
I’m doing something with higher level custom tools that manage dependencies across hundreds of projects that assumes that that portion of the filename is the full 40 character hash, and this breaks that.
I know, a reasonable rebuttal to that is that this is an internal implementation detail, and it’s not part of any documented API, and that the storage on the filesystem could change at any time, and that I simply shouldn’t be doing that.
Nevertheless, I suspect that it is an oversight that the leading zero is lost in this case, and it would likely be a very trivial fix to add it. Compare to GRADLE-2456, in which the leading zero had been lost when publishing an artifact to Artifactory (observed in 1.1, fixed in 1.3-rc-1).
I first observed this in gradle 1.7, but I just tested it with the newly released gradle 2.1 (which is what is shown above), and it is still present.