Chapter 16
The Gradle Wrapper

There is a simple and good news. Gradle provides a solution for this. It ships with a Wrapper task.^{1 2} You can create such a task in your build script.

You usually explicitly execute this task (for example after a switch to a new version of Gradle). After such an execution you find the following new or updated files in your project folder (if the default configuration is used).

All these files should be submitted to your version control system. The gradlew commands can be used exactly the same way as the gradle commands.

16.1 Configuration

If you run Gradle with gradlew, Gradle checks if a Gradle distribution for the wrapper is available. If not it tries to download it, otherwise it delegates to the gradle command of this distribution with all the arguments passed originally to the gradlew command.

You can specify the download URL of the wrapper distribution. You can also specify where the wrapper should be stored and unpacked (either within the project or within the gradle user home dir). If the wrapper is run and there is local archive of the wrapper distribution Gradle tries to download it and stores it at the specified place. If there is no unpacked wrapper distribution Gradle unpacks the local archive of the wrapper distribution at the specified place.

All the configuration options have defaults except the version of the wrapper distribution. If you don’t want any download to happen when your project is build via gradlew, simply add the Gradle distribution zip to your version control at the location specified by your wrapper configuration.

For the details on how to configure the wrapper, see Wrapper API

If you build via the wrapper, any existing Gradle distribution installed on the machine is ignored.

16.2 Unix file permissions

The Wrapper task adds appropriate file permissions to allow the execution for the gradlew *NIX command. Subversion preserves this file permission. We are not sure how other version control systems deal with this. What should always work is to execute sh gradlew.

16.3 Environment variable

Some rather exotic use cases might occur when working with the Gradle Wrapper. For example the continuos integration server goes down during unzipping the Gradle distribution. As the distribution directory exists gradlew delegates to it but the distribution is corrupt. Or the zip-distribution was not properly downloaded. When you have no admin right on the continuous integration server to remove the corrupt files, Gradle offers a solution via environment variables.