[GRADLE-1253] Faulty SHA1 signatures when uploading artifacts Created: 14/Dec/10  Updated: 07/Apr/14  Resolved: 07/Apr/14

Status: Resolved
Project: Gradle
Affects Version/s: 0.9-rc-3
Fix Version/s: None

Type: Bug
Reporter: Vaclav Pech Assignee: Unassigned
Resolution: Not A Bug Votes: 1


The GPars Gradle build is causing faulty SHA1 signatures to be written in the Codehaus repository during an uploadArchives task. This is something specific to the GPars build, since if I do a Gant uploadArchives on the same machine to the same Codehaus snapshots repository the SHA1 signatures written are correct. Certainly I think we can rule out my machine as the culprit and also Codehaus – at least per se.
(Russel Winder)

We also had this problem with some of the NoSQL jars we published and it is a serious problem. A previous workaround I used was to to publish first with the webdav-jackrabbit wagon (1.0-beta-7) Unfortunately this resulted in bad SHA1 signatures so afterwards I published again using the plain HTTP wagon "org.apache.maven.wagon:wagon-http:1.0-beta-6"
Note you can't publish the first time with the plain HTTP wagon, because it fails to create the proper directory structure
This worked once, but recently I tried the same process and failed miserably. I had to generate valid SHA1 files for each jar/pom and manually connect to the Codehaus repo and overwrite them by hand to fix the problem
(Graeme Rocher)

Luke Daley has meanwhile suggested using wagon-http-lightweight:1.0-beta-6, which seems to work for me, although with the same directory creation limitation.

Comment by John Gibson [ 15/Mar/11 ]

I've encountered the same problem when deploying artifacts using the webdav wagon client, and I believe that it is really a Maven Wagon bug: WAGON-304. A larger discussion of the original issue can be found in this maven issue: MNG-4235. Apparently the problem is fixed for the plain HTTP wagon.

What I'm observing is that the file is uploaded once anonymously and then that request is rejected by the server. Maven's client then retries the upload with authentication and it succeeds. However, the webdav client calculates the checksum on the fly during the upload and neglects to reset the checksum between upload attempts. You can test this theory for yourself by running: cat build/libs/<yourjar>.jar build/libs/<yourjar>.jar | sha1sum

Generated at Wed Jun 30 11:50:51 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.