Non-matchng SHAs when depending on jenkins repository in new project

[eboto]

Hello,

My team is having troubles pulling the artifact from the jenkins repository. We get this error when including the artifact -- looks like a SHA that doesn' tmatch. Have you seen anything like this?

[error] {file:/Users/eboto/code/eg-eclipsetest/}website/*:update: sbt.ResolveException: download failed: uk.me.lings#scala-guice_2.9.1;3.0.1-SNAPSHOT!scala-guice_2.9.1.jar
[info] Updating {file:/Users/eboto/code/eg-eclipsetest/}website...
[info] downloading https://jenkins-codingwell.rhcloud.com/job/Scala-Guice/lastSuccessfulBuild/artifact/repo/uk/me/lings/scala-guice_2.9.1/3.0.1-SNAPSHOT/scala-guice_2.9.1-3.0.1-SNAPSHOT.jar ...
[warn]  [FAILED     ] uk.me.lings#scala-guice_2.9.1;3.0.1-SNAPSHOT!scala-guice_2.9.1.jar: invalid sha1: expected=81b0b0b06ddf524792748a1daed6f21ad3299ac9 computed=671c89ef2d215bf3c0c81bcb6c2ee339f7a58be0 (10596ms)
[warn]  [FAILED     ] uk.me.lings#scala-guice_2.9.1;3.0.1-SNAPSHOT!scala-guice_2.9.1.jar: invalid sha1: expected=81b0b0b06ddf524792748a1daed6f21ad3299ac9 computed=671c89ef2d215bf3c0c81bcb6c2ee339f7a58be0 (10596ms)
[warn] ==== scala-guice: tried
[warn]   https://jenkins-codingwell.rhcloud.com/job/Scala-Guice/lastSuccessfulBuild/artifact/repo/uk/me/lings/scala-guice_2.9.1/3.0.1-SNAPSHOT/scala-guice_2.9.1-3.0.1-SNAPSHOT.jar

[tsuckow]

Thats... odd.

[tsuckow]

Ok, I just used http://antimatter15.github.com/js-typed-array-sha1/

and got

'81b0b0b06ddf524792748a1daed6f21ad3299ac9'
which matches from the *.sha1 file
'81b0b0b06ddf524792748a1daed6f21ad3299ac9'

You can check for yourself:
https://jenkins-codingwell.rhcloud.com/job/Scala-Guice/lastSuccessfulBuild/artifact/repo/uk/me/lings/scala-guice_2.9.1/3.0.1-SNAPSHOT/

Maybe proxy between you and build server ¯\ (o_o) /¯

[eboto]

Hmm yes when I sha it manually I get the right result too. But yet somehow when resolving through SBT it consistently fails across multiple machines and internet connections. I made a test project to help you repro. Here's how:

• rm -rf ~/.ivy2/cache/uk.me.lings
• git clone git://github.com/eboto/scalaguice-sha-bug.git
• cd scalaguice-sha-bug
• ./sbt update

You will end up with a stack trace instead of the scala-guice jars! I'm not sure if it's meaningful, but the calculated sha is always different. Thus far i've gotten at least 6 unique ones. Does that not happen to you with that test project?

[tsuckow]

I believe this may be a bug in SBT, I submitted a bug with them. If it isn't, then the only thing I can think of is a bug in the reverse proxy on OpenShift or in the Jenkins servlet engine.

harrah/xsbt#580

This does not occur for me with Gradle.

If you have any other (real) maven repo you recommend hosting the snapshots at, I am all ears.

[eboto]

Wow...awesome. Thanks for filing that bug with sbt!

[tsuckow]

Hopefully we will get around this when #4 is finshed.

[nbauernfeind]

This shouldn't be an issue anymore now that it has been released to maven central.