For some reason gradle is not downloading dependencies from Maven Central. We have a private Nexus repository set up as well and for some reason gradle is looking there for dependencies and not Maven Central.
I get a ton of errors similar to:
Failed to get resource: HEAD. [HTTP HTTP/1.1 400 Repository version policy: SNAPSHOT does not allow version: 1.5.0.RELEASE: http://*****/repository/******/io/pivotal/spring/cloud/spring-cloud-services-dependencies/1.5.0.RELEASE/spring-cloud-services-dependencies-1.5.0.RELEASE.pom]
I swear I have resolved this before when I first set it up, but cannot replicate. In order for me to hit Maven Central, I must have the proxy set up and have Nexus as an exclusion to the proxy.
This all works locally, but the issue comes in when dealing with Jenkins and the Sonarqube plugin. Locally I've tried various proxy settings (remove systemProps or even system env variables), but errors are not the same (ie cannot find host).
Any idea why it's not able to download from Maven Central?
Update: So I was able to narrow it down a little further. When using Jenkins and Sonarqube withSonarQubeEnv
block, something happens with how gradle resolves dependencies. See 3 examples:
// #1 This breaks when SNAPSHOT is declared first
repositories {
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
// #2 This works since mavenCentral() is first:
repositories {
mavenCentral() // <---------- Maven Central
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
}
// #3 This also works because no failing version policy:
repositories {
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
This works fine when not using withSonarQubeEnv
in Jenkins. Why would order matter when using withSonarQubeEnv
?
Figured it out. It had nothing to do with withSonarQubeEnv
block in Jenkins. The Sonarqube sample settings for gradle had the --info
flag added, which I was using for testing. I added that to my build step and found same errors. I even cleaned the cache in the .gradle folder and everything still downloaded.
I suppose Gradle does something a little misleading when it tries to resolve dependencies. It spits out info messages when retrieving a RELEASE artifact from a SNAPSHOT repository, but it still continues to retrieve the artifact from the other listed repositories.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.