Hope this isn’t a dumb question but I couldn’t figure it out… A few days ago, I started the gradle-1.2 migration (mostly from milestone 7 and rc3) by trying to build our project with it. The first thing it did was re-download the dependencies, most of them from maven central. However,I got errors like "Couldn’t HEAD to ". Since this is persisting since days, I tried to access the artifacts from the browser and indeed, when e.g. going to ‘http://repo1.maven.org/maven2/org/owasp/antisamy/antisamy/1.4.3/antisamy-1.4.3.pom’ via browser or wget, I got “connection reset by peer”. After a bit of testing, it seems like if I point my browser to ‘http://repo1.maven.org/maven2/org/owasp/antisamy/antisamy/1.4.3/’ and then “click” on the POM, it downloads, after which it works in gradle too (the next artifact fails again of course) so this seems like an intentional behavior, as it also occurs with the central mirror ‘http://uk.maven.org/maven2’ but the ‘http://maven.antelink.com/content/repositories/central/’ mirror works. Does anybody experience this too? Can someone give advice on this?
Probably a good question for the maintainers of Maven Central. I haven’t seen this in practice with Gradle, but when I clicked the links you provided, I got the same weird behavior. I could only open the POM after I had opened its parent directory.
I’ll add some more info on this issue after “bumping” it.
curl http://repo1.maven.org/maven2/org/gradle/api/plugins/gradle-android-plugin/1.2.1/gradle-android-plugin-1.2.1.jar
curl: (56) Recv failure: Connection reset by peer
What’s weird is that I don’t see this running mvn commands, but when I run gradle it complains about the connection reset, and as you can see above curl fails as well. If I navigate to http://repo1.maven.org/maven2/org/gradle/api/plugins/gradle-android-plugin/1.2.1 it seems I can download it sometimes but other times I get a connection reset. I can’t seem to find a pattern for the browser, but I think the cURL and wget fail 100% of the time.
I’m still searching for some sort of bug reporting system for maven central, but I figured I’d rule out the case that Messi’s dependencies are the only ones affected.
This is an old thread, but it since it seems to happen consistently to some of us, I thought I’d add some information. I see this problem virtually every time I need to download a “large” jar from Maven Central, where “large” is > 25 MB, like the gwt-dev jar. The symptom is that the download successfully gets to within a few percent of finishing (sometimes within a few bytes) and then gets reset. Of course, this kills the build. If I retry, I get the same behavior, so I’m pretty much stuck.
My (nasty) workaround has been to download the jar with wget and put it into gradle’s cache by hand. This usually works because wget automatically attempts to retry and continue the download. When the reset occurs, wget’s retry attempt receives the last few bytes, and the download succeeds.
The underlying cause appears to be an intermittent problem on Maven Central, usually reported by people behind a corporate firewall (like me):
That bug report is marked closed, with no explanation for how it was fixed for the last person that reported it… but I suspect it’s still happening intermittently to a lot of us.
This isn’t gradle’s fault, but it would be nice if gradle included the sort of retry-and-continue behavior that wget does, which would probably be useful in more scenarios than just this one. One retry typically seems to be enough, and it would save a lot of headaches. (But I think it’s likely to be a complicated problem to solve inside gradle.)
We have the same issue in our corporate network. A way to use the wget retry semantics would be great. Or to know how to modify the firewall to make this work.
