The http proxy settings don't work

Old Forum Archive
1

Hi,

I am trying to run gradle command line (1.4 version) to build the war project. I am behind a http proxy server. So, I setup a gradle.properties file in the .gradle directory of my project (I have also tried to place the file in the project home directory. Still, I cannot download the dependencies. Here is the content of the file:

systemProp.http.proxyHost=host ip systemProp.http.proxyPort=host port systemProp.http.proxyUser=user

systemProp.http.proxyPassword=password

I have two questions:

  1. What am I doing wrong when I setup the proxy settings?

  2. If somehow this method works, is there a way to not type the user and password and have gradle take it from windows (the way maven 3.x does - setings.xml specifies constants: WINDOWS USER, PASSWORD so a user does not hard code the security info)?

By the way, I have tried with maven and it works - it can download the dependencies.

Thanks,

Misak Boulatian

email: misak.boulatian@broadridge.com

2

The HTTP proxy support is certainly not perfect, and is something we’re still working on.

Without more information, I can’t tell what’s going wrong. Your best bet is to send the entire output of running your build like this:

gradle --debug --refresh-dependencies [your-task-name]

Please post the debug output via GitHub Gist, rather than inline in your forum posting.

To answer your second question, you can set these properties in various ways: see http://www.gradle.org/docs/current/userguide/build_environment.html for more details.

3

Hi Daz,

Thanks for responding. Here is the link to GitHub Gist: https://gist.github.com/4674838.

My build.gradle file is very simple:

apply plugin: ‘war’

repositories {

mavenCentral() }

dependencies {

compile ‘javax:javaee-web-api:6.0’

testCompile group: ‘junit’, name: ‘junit’, version: ‘4.+’

}

sourceCompatibility = 1.7 version = ‘1.0’

Thanks for your help again. Misak

4

It doesn’t look like your proxy settings are being applied in this build log. Did you follow the instructions in http://www.gradle.org/docs/current/userguide/build_environment.html ? (Your ‘gradle.properties’ needs to be in either your ‘gradle user home’ or your main project directory.)

First thing to do would be to add a debug statement to your build like:

println "http.proxyHost = " + System.getProperty("http.proxyHost")

This will let you be sure that the system properties are being set.

Once you have the properties being applied correctly, please send the debug logs if it still doesn’t work.

5

Hi Daz,

I updated the revision with a new log. Please take a look at. My gradle.properties is in the main project directory where build.gradle file is located. I had to break the output because it was in the infinite loop trying to connect.

Please not that for security purposes I commented out the password in the log file.

Thanks,

6

Are you running with ‘gradle-1.4’ final? This looks a lot like GRADLE-2650, which was fixed (at least for the user who reported it) in the final 1.4 release.

If you are definitely running with the final release, then it would be worth trying to add:

systemProp.http.keepAlive=true

to your ‘gradle.properties’ to see if that helps.

7

I use the gradle -1.4 final. I have exactly the same problem as the issue described in GRADLE-2650. Even after using keepAlive attribute I still have the same problem - it results to infinite loop of similar messages as in the issue.

Thanks, Misak

8

As the reporter of GRADLE-2650 I just want to mention that I’m NOT experiencing this issue in 1.4 final anymore.

9

As I said, I tried with httpcomponents-client-4.2.3 and 4.2.1 by renaming them as 4.2.2. I still have the same problem. One difference, with 4.2.1 when I type gradle dependencies, I get the FAILED message right away but with 4.2.3 and 4.2.2 I get in the infinite loop. So, I want to mention that the maven still works without specifying any user name and password in settings.xml file (Just proxyHost and proxyPort). So, this means that your solution with keepAlive is not the one that covers all the NTLM issues. You need to look at this issue as a serious bug and change your approach about it.

Thanks, Misak

10

I just want to inform you that after long debugging, google searches, and headaches I gave up on using remote repository through gradle. It definitely has a lot of issues and since, you guys still think you resolved it (DEFINITELY NOT!), I started looking for alternatives. Thankfully, I found JFrog’s open source version of Artifactory that had a remote repository feature. So, now I access the mavenCentral through Artifactory’s remote folder feature and everything works fine.

Thanks and hopefully one day you fix it. Until then may be you can recommend my solution to other frustrated customers. Misak

11

Thanks for the feedback, and sorry that the current implementation of NTLM in Gradle isn’t working for you. We definitely fixed one problem (GRADLE-2650) in ‘gradle-1.4’ but obviously didn’t fix the problem you’re seeing.

Providing better support for NTLM is certainly on our priority list, but as with any open-source project we are limited by the development resources we have available. NTLM bugs are particularly tricky to deal with, since there are so many different implementations of NTLM servers out there, each with it’s own quirks.

Your suggestion of using a local Artifactory instance is certainly a valid workaround: glad you found a way to get Gradle working for you.