Sorry for the delayed response. Yes, that's what I meant. Is it possible the sha1 was downloaded from a proxy where it is incorrect? You can check the audit log to confirm.
Do you have the consumer to correct missing checksums enabled or disabled? (check the repository scanning admin page) On 11/03/2011, at 5:20 AM, kokaku wrote: > > Not sure exactly what you mean by 'compared them by hand' - I have manually > generated a SHA1 hash on the uploaded and downloaded files (the same) and > eyeballed the SHA1 hash that Archiva thinks it should be (different). > > > brettporter wrote: >> >> Have you compared them by hand to confirm the result? The only issue I can >> think of is if there is an unsupported format (some write ust the >> checksum, some write the filename and the checksum, etc.) >> >> On 10/03/2011, at 6:35 AM, kokaku wrote: >> >>> >>> I am trying to upload this JAR to Archiva >>> http://old.nabble.com/file/p31116227/mybatis-generator-core-1.3.1.jar >>> mybatis-generator-core-1.3.1.jar >>> >>> I can upload and download the JAR through the web interface. The problem >>> is >>> that when I use Ivy, it fails because the SHA1 on Archiva is different >>> from >>> the downloaded file. The SHA1 on the downloaded file does match the SHA1 >>> on >>> the uploaded file. So, it looks like somehow, Archiva has created invalid >>> SHA1 information. >>> >>> Has anyone seen this behavior before? Does anyone have a solution or >>> workaround? >>> -- >>> View this message in context: >>> http://old.nabble.com/Invalid-sha1-tp31116227p31116227.html >>> Sent from the archiva-users mailing list archive at Nabble.com. >>> >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> > > -- > View this message in context: > http://old.nabble.com/Invalid-sha1-tp31116227p31118362.html > Sent from the archiva-users mailing list archive at Nabble.com. > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
