If you’re running the gradle wrapper in a portal network environment, the wrapper may think it has downloaded a gradle distribution, but instead the contents are actual a portal HTML page asking for login credentials or access payment or terms of service acceptance etc.
And then obviously executing the “code” will fail.
A number of people have run into this using Android Studio; see for example http://stackoverflow.com/questions/20399277/cause-error-in-opening-zip-file-android-studio
Somebody filed a request that in Android Studio we should verify the gradle wrapper before trying to use it: https://code.google.com/p/android/issues/detail?id=69582
I was about to do that when I realized that it would probably be much better for the wrapper itself to check this, such that it works not just when Gradle is run from Studio, but whenever anyone tries to run the gradle wrapper, and it fails in a scenario like the above.
We probably don’t need to do anything super fancy, but the shell/.bat script could, before attempting to launch the “jar” file, do something simple to make sure it’s at least a .jar file.
There are several possible ways to do that; I’m not sure what’s most portable in terms of script commands available to the shell; the “file” command is obviously useful, and you could just run say “jar tf gradle/wrapper/gradle-wrapper.jar META-INF/MANIFEST.MF” to see if it succeeds etc. The most efficient thing might be to look for the magic number at the beginning of the .jar file. I’m not certain what it is; in several files I’ve looked at it’s
P
K 003 004
Probably the simplest expedient thing to do is to simply see if the downloaded .jar file starts with “<html” and if so, state that something is wrong with the network connection!
– Tor