I have a number of projects that build fine behind a proxy (using gradle wrapper) in various versions of gradle up to and including gradle 2.0.
But once I upgrade the gradle wrapper to 2.1, I can no longer build on machines (i.e. my Jenkins server) without direct internet access (behind a proxy server). It seems like gradle (wrapper) 2.1 added a dependency on org.codehaus.groovy.modules.http-builder:http-builder:0.7.1 and that dependency has to be resolved when one of the following plugins is loaded: java, eclipse, jacoco.
We use an internal artifact repository (artifactory) so that our builds do not require direct internet access, but even configuring a repository in a buildscript section does not cause gradlew to use our internal artifact repository to resolve this dependency.
If I configure http(s).proxyHost and http(s).proxyPort then gradlew is able to resolve the dependencies that it needs to do the build, but this is not optimal because it requires me to do some special proxy detection in my gradle builds or force everyone to use the proxy server. This sucks because I really wanted to upgrade to gradle 2.1 for the dependency exclusion improvements in the maven-publish plugin.
Inspecting the dependencies of Gradle 2.1, the ‘http-builder’ module you mention is not present. (We use the ‘groovy-all’ module to include all of the required Groovy modules). Can you try running ‘./gradlew --version’ and ‘./gradlew help’ on the Jenkins server to see if where the new dependency is coming from?
Thanks for responding and thanks for the tip that this shouldn’t be coming from Gradle.
It turns out that someone sneakily added a buildscript configuration to one of our build scripts (that gets included via “apply from”) which was adding a mavenCentral() repository to resolve http-builder.
It’s still curious that this didn’t affect our ability to build with the wrapper in Gradle 2.0, but I certainly understand why it doesn’t work in Gradle 2.1; I would just have expected it to not work in both cases. Perhaps there was some change in the way that the script compilation works?
One possibility is that the dependency was already in the cache on CI for Gradle 2.0, so didn’t require any network access. The cache format changed for Gradle 2.1, so we need to access the network to determine if the Gradle 2.0 cached artifacts are up to date.