This standard setting is currently not respected by Gradle, with the proxy being used even if the host was specified with this setting.
This is working fine for me. Given a simple build file:
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile 'commons-lang:commons-lang:2.5'
}
The if I do:
➜
gradle -g home -s -Dhttp.proxyHost=foo.bar -Dhttp.proxyPort=8080 dependencies
I get:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':dependencies'.
> Could not resolve all dependencies for configuration ':compile'.
> Could not resolve group:commons-lang, module:commons-lang, version:2.5.
Required by:
:http_proxy:unspecified
> Could not GET 'http://repo1.maven.org/maven2/commons-lang/commons-lang/2.5/commons-lang-2.5.pom'.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':dependencies'.
.........
Caused by: java.net.UnknownHostException: foo.bar
.....
But if I then do:
➜
rm -r home
➜
gradle -g home -s -Dhttp.proxyHost=foo.bar -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=repo1.maven.org dependencies
The build succeeds. Note that the second time I’m setting mavenCentral as a nonProxyHost. Also note that I’m using a fresh gradle home each time. Otherwise you could hit caching since proxy settings are not considered in our repository definition.
Is this with m7? I don’t remember seeing this output.
What are we caching here? The fact that the repository is unreachable, or the fact that the artifact wasn’t found?
This is the output from M9, but I’ve tested on M7 and get the same result.
We don’t cache failed lookups, but we do cache the fact that an artifact is missing from a repository. Since M7 doesn’t have ‘–refresh=dependencies’, I find that using a fresh Gradle home can help to investigate issues with dependency resolution.
In fact, in this particular case, cleaning the gradle home isn’t required between the 2 executions.
We couldn’t get nonProxyHosts to work (albeit we never cleaned the full Gradle user home). Removing proxyHost did work. I can’t see anything wrong with our nonProxyHosts value (we tried several variations). Looking at the Gradle codebase, my impression is that the nonProxyHosts information isn’t passed on. What am I missing?
Why do we cache the fact that an artifact is missing from a repository? Isn’t it always better to retry than to fail straight away? Among other things, this would make troubleshooting a lot easier - if someone fixes a missing dependency problem, all users will “get” the fix immediately. I believe this is how it works in Maven.
I’m pretty sure that nonProxyHosts is working: I trust tests more than code inspection. In M7, the code you refer to is used directly. In M9 we pass the responsibility to HttpClient, which uses java.net.ProxySelector.
Regarding caching missing artifacts: this is vital to the way we do dependency resolution. One improvement would be that if we don’t find the artifact in any repository we then perform a fresh resolve for repositories that have cached that it was missing. In Gradle-1.0, ‘–refresh-dependencies’ will have to do.
Alternatively (and more accurately), we should invalidate the cached entries for an http repository when the http proxy settings change. This should probably happen at the resource level, so that an http resource is invalidated when the http proxy settings change.
This way, we pick up resources that were previously not available but now are, and resources that used to be available but now are not. And we handle any weirdness that arrises if the proxy happens to be doing something different based on the user credentials, and the credentials change.
@Daz: When I looked, I could only find unit tests for this (not that I expected anything more than that), and it wasn’t clear to me that they proved that nonProxyHosts was working.
Regarding the caching, why is it vital to cache “artifact not found”? I can see this cause lots of pain for users. I’m not so concerned about 1.0, but we should try to set this straight eventually.
Repositories are ordered, and we iterate over the repositories in turn checking each for the requested module. If we didn’t cache the fact that an artifact was ‘missing’, we’d be making extra HTTP requests on every resolve to check.
The alternative is to use a cached module from any repository if it exists, before checking. The problem is that resolution then becomes non-deterministic, as it can depend somewhat on what has been cached previously. This is probably fine most of the time, but it doesn’t feel right.
A good solution would be to resolve again, bypassing the cache, if the initial resolve using the cache didn’t locate the artifact in any repository. That would help a user recover from a misconfigured repository, while remaining efficient in the general case.
The alternative is to use a cached module from any repository if it exists, before checking. The problem is that resolution then becomes non-deterministic, as it can depend somewhat on what has been cached previously. This is probably fine most of the time, but it doesn’t feel right.
We definitely can’t do this. While the chances of getting the wrong artifact are low, we can’t undo our work to make resolution as deterministic as possible.
Just downloaded jsvn, and went to execute graldew.bat At home without a proxy server, but a WLAN firewall, it works perfect !!! At our company, behind a proxy server/firewall it fails and WireShark clearly shows that Authentication wasn’t any good. (is requierd) But I have passed to the java command used in the gradlew.bat all arguments as we do normal. in fact also in the code I found that http.proxyUser and http.proxyPassword are used to catch from system variable the important proxy-authentication information. But where is http.proxyHost and http.proxyPort used to catch this information? And where is probabbly http.auth.preference=Basic used to deliver a hint to the proxy server about which authentication schema to use. Josef
E:\asf\svnkit\trunk>gradlew.bat “E:\asf\svnkit\trunk” " -Xmx512m -Dhttp.auth.preference=Basic -Dhttp.proxyHost=bcproxyserver.ch.winterthur.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=C770817 -Dhttp.proxyPassword=May12orbxorbx -Dorg.gradle.wrapper.properties=E:\asf\svnkit\trunk\gradle\wrapper\gradle.prope rties" #Fri Apr 22 16:45:48 CEST 2011 distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists distributionUrl=http://repo.gradle.org/gradle/distributions/gradle-1.0-rc-3-bin.zip http.proxyHost=proxyserver.ch.winterthur.com http.proxyPort=8080 http.proxyUser=C770817 http.proxyPassword=orbxorbx http.nonProxyHosts=localhost http.auth.preference=Basic “C:\Program Files\Java\jdk1.6.0_30/bin/java.exe” -Xmx512m -Dhttp.auth.preference=Basic -Dhttp.proxyHost=proxyserver.ch.winterthur.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=C770817 -Dhttp.proxyPassword=orbxorbx -Dorg.gradle.wrapper.properties= E:\asf\svnkit\trunk\gradle\wrapper\gradle.properties -classpath E:\asf\svnkit\trunk\gradle\wrapper\gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain Downloading http://repo.gradle.org/gradle/distributions/gradle-1.0-rc-3-bin.zip
Exception in thread “main” java.io.IOException: Server returned HTTP response code: 407 for URL: http://repo.gradle.org/gradle/distributions/gradle-1.0-rc-3-bin.zip
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at org.gradle.wrapper.Download.downloadInternal(Download.java:49)
at org.gradle.wrapper.Download.download(Download.java:37)
at org.gradle.wrapper.Install.createDist(Install.java:54)
at org.gradle.wrapper.Wrapper.execute(Wrapper.java:44)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:37)
E:\asf\svnkit\trunk> again WireShark reports that no Autrhentication information was passed to proxy server bit is required there.
Josef, If I understand correctly this isn’t an issue with ‘-Dhttp.nonProxyHosts’.
Would you mind please opening a new topic so we can track your issue.
Usually proxy settings work just fine. Have you tried ‘–refresh-dependencies’? Also, according to the console output it’s failing to download Gradle itself, not a regular dependency. This may make a difference.
Thank you Peter, This morning I logged into our domain with the smart card. normal I do so with username and password (as it had made a difference using username and password at the proxy when one has logged in by the smart card. Since a few week they have solfed that problem and both methods work now.
This morning I downloaded and used TortoiseGit and the download of gradle went very successfully.
Then I went into a MinGW32 console and did,
$ cd gradle
C770817@C036357 /e/gradle (master) $ ls README.md build.gradle buildSrc config gradle gradlew gradlew.bat performanceTest settings.gradle src subprojects
C770817@C036357 /e/gradle (master) $ /bin/sh ./gradlew Downloading http://services.gradle.org/distributions/gradle-1.0-rc-3-bin.zip
Exception in thread “main” java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:781)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:640)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:778)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:640)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
at org.gradle.wrapper.Download.downloadInternal(Download.java:61)
at org.gradle.wrapper.Download.download(Download.java:49)
at org.gradle.wrapper.Install.createDist(Install.java:51)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:47)
C770817@C036357 /e/gradle (master) $
We see the same error when we go by a browser to the gradle download page and download the -all and the -bin.zip files from the most current release. Curios the -src.zip is not affected. But the other tow come down but are not closed properly. And after some time out the archiver WinRAR opens and shows a corrupt archive which by TugZIP or WinRAR can be browsed but not extracted. So the ZIP has to be considered corrupt. We sit behind a firewall/proxy.
Doing the same from home without a firewall works.
For me, the wrapper has problems with communicating through the firewall even all the -Dhttp.proxy* system variables are set, I used a GRADLE_OPTS=-Dhttp.proxy* for all the known proxy settings;
What I beg for is to tell me if on may setup something is wrong. As shown in the previous post.
You might be running into http://issues.gradle.org/browse/GRADLE-1679, which says that proxy authentication isn’t currently support for downloading the Gradle wrapper. (However, it is supported when working with Maven/Ivy repositories). In that case, you can use the workaround mentioned in the issue, or use one of the workarounds I mentioned earlier (download Gradle manually or host it yourself).
I haven’t heard of anyone else having problems with downloading Gradle from the Gradle homepage. This might be a problem on your side.
By having the following in your gradle.properties file, and a wrapper generated with M8 or later, the gradle wrapper will download via an authenticated proxy server:
systemProp.http.proxyHost=my_proxy
systemProp.http.proxyPort=8081
systemProp.http.proxyUser=my_user
systemProp.http.proxyPassword=my_password
There are a number of things that might be causing your problems, but if you’re having issues downloading via a browser as well, then I suspect that something in your network firewall is preventing the gradle download.
I solved of this way: ./gradlew -Dhttp.proxyHost=10.12.0.9 -Dhttp.proxyPort=8002 clean build
java bar code http://www.keepautomation.com/products/barcode_fonts/