-
You generate it once, and again when you’d like to change the version of Gradle you use in the project. There’s no need to generate is so often. Here are the docs. Just add
wrapper
task tobuild.gradle
file and run this task to get the wrapper structure.Mind that you need to have Gradle installed to generate a wrapper. Great tool for managing g-ecosystem artifacts is SDKMAN!. To generate a gradle wrapper, add the following piece of code to
build.gradle
file:task wrapper(type: Wrapper) { gradleVersion = '2.0' //version required }
and run:
gradle wrapper
task. Add the resulting files to SCM (e.g. git) and from now all developers will have the same version of Gradle when using Gradle Wrapper.
With Gradle 2.4 (or higher) you can set up a wrapper without adding a dedicated task:
gradle wrapper --gradle-version 2.3
or
gradle wrapper --gradle-distribution-url https://myEnterpriseRepository:7070/gradle/distributions/gradle-2.3-bin.zip
All the details can be found here
From Gradle 3.1
--distribution-type
option can be also used. The options are binary and all and bin. all additionally contains source code and documentation. all is also better when IDE is used, so the editor works better. Drawback is the build may last longer (need to download more data, pointless on CI server) and it will take more space.
-
These are Gradle Wrapper files. You need to generate them once (for a particular version) and add to version control. If you need to change the version of Gradle Wrapper, change the version in
build.gradle
see (1.) and regenerate the files. -
Give a detailed example. Such file may have multiple purposes: multi-module project, responsibility separation, slightly modified script, etc.
-
settings.gradle
is responsible rather for structure of the project (modules, names, etc), while,gradle.properties
is used for project’s and Gradle’s external details (version, command line arguments-XX
, properties etc.)