In short, I updated my jsvn subversion trunk. surprise - jsvn today builds using gradle, no longer ant. so for me new problems to start with - PROXY, always the same with proxy. with maven, with ant, with jsvn, with git, with mercury; well lets go with gradle. The first question: how to I inform gradle about the proxy-server:port to connect to and how to tell the proxy about username password and authentication scheme preferences, this because most of the time, negotiating an authenticationschema fails anyway due to the various flavors such work can have. For jsvn gradlew.bat I modified the java command to get the -Dhttp.proxy* switches set. It does not work, it fails, WireShark protocol analyzer shows is clearly: “Authentication Requuired”. So how do we pass to the down-load-wrapper code all this information: Taking the sources, in particular the wrapper, seeking for proxy, revelaed that only username and password is once retreived from system variables. But what about proxy host and port and auth preference?
In short; from home the same task works when I start to build jsvn using gradlew.bat but behind a fire wall that is a no go.
I’d say GRADLE-1679 is not actually fixed. The committer who closed the ticket (i.e. Daz) should be available to comment on this soon. I suggest keeping an eye on that ticket.
GRADLE-1679 was fixed in 1.0-milestone-8. 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:
Gradlew downloads gradle distributions via ‘java.net.URL.openConnection().getInputStream()’ with password authentication provided as described in http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-auth.html. This mechanism should fully support ‘http.auth.preference’ as well, if you specify the system property as described above.
OK then - he problem is with the content of the ZIP file and our lovely preventig firewall. changing the distributionURL in gradle-wrapper.properties to distributionUrl=http://www.ks-net.ch/ant-1.7.1-jars.tar.gz results in
E:\gradle>gradlew.bat
Downloading http://www.ks-net.ch/ant-1.7.1-jars.tar.gz
..........................................................................................................................................................
Unzipping C:\Users\C770817\.gradle\wrapper\dists\ant-1.7.1-jars.tar4ihnpp4ocnksjkkttitrc65sc\ant-1.7.1-jars.tar.gz to C:\Users\C770817\.gradle\wrapper\dists\ant-1.7.1-jars.tar4ihnpp4ocnksjkkttitrc65sc
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:127)
at java.util.zip.ZipFile.<init>(ZipFile.java:143)
at org.gradle.wrapper.Install.unzip(Install.java:148)
at org.gradle.wrapper.Install.createDist(Install.java:65)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:47)
E:\gradle>
So it is the content of the ZIP which our FW does not like. And ant-1.7.1-jars.tar.gz can make it. What I would like to know from gradle.orgt is: could it be that re-packaging the same content into a .tar.gz file can pass our fire wall? In this case, maybe somebody can do me a favor, just for a test, and re-pack and have gradle-1.0-rc-3-bin.tar.gz at the same location as the distribution zip files are. After that I migth have sufficient munition to ask our AXA Tech Service Department about removing this filter from the Firewall/Proxy. Josef