Basically, read this: http://forums.gradle.org/gradle/topics/inconsistent_handling_of_g_and_dgradle_user_home_on_the_command_line.
The reason is probably that the GradleWrapperMain class uses this method to find gradle home (code from gradle REL-1.6):
private static File gradleUserHome() {
String gradleUserHome = System.getProperty(GRADLE_USER_HOME_PROPERTY_KEY);
if (gradleUserHome != null) {
return new File(gradleUserHome);
} else if ((gradleUserHome = System.getenv(GRADLE_USER_HOME_ENV_KEY)) != null) {
return new File(gradleUserHome);
} else {
return new File(DEFAULT_GRADLE_USER_HOME);
}
}
This ignores the command line switches completely, and uses the default home if no env nor a sysprop have been defined. This makes that the line from the user guide (chapter 61. Gradle Wrapper, right under example 61.2):
The gradlew command can be used exactly the same way as the gradle command.
not really true. (Emphasis in the above quote comes from the user guide as well; ‘exactly’ is underlined also, but I don’t know how to do it in markdown.)
The problem is also that this wrong gradle home is used to read gradle.properties, which can break the build in an obscure way.
The method above should use the arguments to see if the path hasn’t been specified there.
wujek