Why do I need to run ./gradlew wrapper twice after updating build.gradle

For a while I’ve been noticing that whenever I change the gradle version in the wrapper task I need to run ./gradlew wrapper twice to have it begin downloading. Is it working as expected, in some sort of 2 phase upgrade inner config followed by lazy download? What’s the procedure by the book to upgrade gradle? I’d expect something like 1) change gradleVersion from 2.8 to 2.9 in build.gradle 2) ./gradlew build

BTW I’ve thinking about using offline configuration for a while, will this hurt the expected behaviour? This is my properties file currently

> cat ~/.gradle/gradle.properties

org.gradle.daemon=true
org.gradle.parallel=true

IIUC, you’re doing something like…

build.gradle:

wrapper { 
   gradleVersion = "2.8"
}
  1. You change gradleVersion to 2.9.
  2. You run gradlew wrapper (which does nothing)
  3. You run gradlew wrapper again (which starts downloading 2.9)

The reason for this is that the wrapper task rewrites the gradle-wrapper.properties file based on the version in build.gradle. The version of the wrapper is still the old version until you run gradlew wrapper again.

Unless you’re using a different URL to download your copy of Gradle, you could remove the wrapper task from build.gradle and just rely on the implicit wrapper task that Gradle has. Then your update process would look like:

  1. gradlew wrapper --gradle-version=2.9
  2. gradlew build (gradle 2.9 would be downloaded here)

WRT using offline configuration (I assume you mean --offline?), you just need to have whichever version of Gradle the wrapper will look for already downloaded once.

1 Like

To get a better grip on understanding this, I cloned a new repo and put that idea in action.

./gradlew wrapper --gradle-version=2.9 --offline

First thing I had happening was having https://services.gradle.org/distributions/gradle-2.4-all.zip downloaded, although the repo already had its own gradle folder, and after that I had some libraries error for not having them on the laptop. So my conclusion is that --offline doesn’t apply for gradle itself. Not a problem, although I didn’ t see that coming.

Cloning the same repo on another folder and running the same command won’t download gradle-2.4 again, so that makes me sure that I didn’t have that file in the first place.