Running gradle behind an authenticated proxy, I am able to apply plugins in the standard way (apply plugin: + buildscript classpath dependency). I provide the proxy settings (host, username and password) through gradle.properties, or directly from the command line (-Dhttps.proxyUser=… etc).
However, the same procedure does not work when applying a plugin through the plugins DSL.
14:09:53.381 [DEBUG] [org.apache.http.impl.client.SystemDefaultHttpClient] CONNECT refused by proxy: HTTP/1.0 407 Proxy Authentication Required … 14:09:53.474 [ERROR] [org.gradle.BuildExceptionReporter] Error resolving plugin [id: ‘com.jfrog.bintray’, version: ‘1.0’] 14:09:53.490 [ERROR] [org.gradle.BuildExceptionReporter] > The response from https://plugins.gradle.org/api/gradle/2.2.1/plugin/use/com.jfrog.bintray/1.0 was not a valid response from a Gradle Plugin Resolution Service: content type is ‘text/html’, expected ‘application/json’
If I browse the portal URL in a browser I am able to see the correct json response.
Could you please test the proxy outside of your browser using a command line utility such as curl? Your browser may be using a pac file which may treat https connections differently (route directly or via a different proxy) which is why it works but command line tools don’t.
The username may need to be in the form DOMAIN\username
You can get curl for windows from here. There is also an NTLM enabled curl build, see the details on this stack overflow post
The working curl command will provide some information on what to feed into the proxy system properties, and also provide you with a starting point you can escalate this with the network engineers at your site.
Please let us know how you go with this.
One final question, is this the first time you have tried using the plugin DSL at this site? (with this proxy). Has it worked previously?
Yes, this is the first time I have tried the plugin DSL, so it did not work previously.
Anyway, as I wrote in my initial post, I am able to work through the plugin resolution by means of the “standard” syntax (not the DSL one). In that case the proxy works (and also works for git and maven).
It is only when I try to apply the “DSL syntax” that the proxy denies the authorization, so it seems to me that the plugin DSL function is somehow following a different path to establish a http connection to the Gradle plugins portal.
You are correct in saying that the Plugins DSL is following a different path. The DSL relies on the plugin portal (plugins.gradle.org) to identify the details that you would previously have to add to the buildscript { … } section of your build.
It would appear that the proxy specified in the command line is preventing access to the https://plugins.gradle.org URL. I’ve worked in corporate environments in the past where the proxy specified on the command line is different to what your browser uses and I have a hunch you may be experiencing the same issue, which is why it works in your browser but not on the command line.
The reason the buildscript way works for you is that its only using http and not https, so the https proxy isnt being used or tested.
It may be worth checking with the network administrators that URL is available via the proxy you have specified. The curl command provided in my last post would verify this too. Can appreciate this isn’t a priority at the moment, however as other projects incorporate the new DSL, you’ll find you will have trouble consuming those builds.
Currently the new plugin DSL can only be used to resolve plugins against the plugin portal or core Gradle plugins. If you want to use third-party plugins that aren’t in the plugin portal you’ll have to continue to use the ‘apply plugin: …’ syntax.