Example 53.1. Using init script to perform extra configuration before projects are evaluated
build.gradle
repositories { mavenCentral()
}
task showRepos << { println "All repos:"
println repositories.collect { it.name }
}
init.gradle
allprojects { repositories {
mavenLocal()
}
}
Output of gradle --init-script init.gradle -q showRepos
> gradle --init-script init.gradle -q showRepos All repos:
[MavenLocal, MavenRepo]
53.4. External dependencies for the init script
In Section 52.5, “External dependencies for the build script”is was explained how to add external dependencies to a build script. Init scripts can similarly have external dependencies defined. You do this using the initscript() method, passing in a closure which declares the init script classpath.
Example 53.2. Declaring external dependencies for an init script
init.gradle
initscript { repositories {
mavenCentral()
}
dependencies {
classpath group: 'org.apache.commons', name: 'commons-math', version:
}
}
The closure passed to the initscript() method configures a ScriptHandler instance. You declare the init script classpath by adding dependencies to the classpath configuration. This is the same way you declare, for example, the Java compilation classpath. You can use any of the dependency types described in Section 43.4, “How to declare your dependencies”,except project dependencies.
Page 321 of 343
Having declared the init script classpath, you can use the classes in your init script as you would any other classes on the classpath. The following example adds to the previous example, and uses classes from the init script classpath.
Example 53.3. An init script with external dependencies
init.gradle
import org.apache.commons.math.fraction.Fraction
initscript { repositories {
mavenCentral()
}
dependencies {
classpath group: 'org.apache.commons', name: 'commons-math', version:
}
}
println Fraction.ONE_FIFTH.multiply(2)
Output of gradle --init-script init.gradle -q doNothing
> gradle --init-script init.gradle -q doNothing 2 / 5
Page 322 of 343
54
The Gradle Wrapper
The Gradle Wrapper (henceforth referred to as the “wrapper) is the preferred way of starting Gradle build. The wrapper is a batch script on Windows, and a shell script for other operating systems. When you start a Gradle build via the wrapper, Gradle will be automatically downloaded and used to run the build.
The wrapper is something you should check into version control. By distributing the wrapper with your project, anyone can work with it without needing to install Gradle beforehand. Even better, users of the build are guaranteed to use the version of Gradle that the build was designed to work with. Of course, this is also great for continuous integration servers (i.e. servers that regularly build your project) as it requires no configuration on the server.
You install the wrapper into your project by adding and configuring a Wrapper task in your build script, and then executing it.
Example 54.1. Wrapper task
build.gradle
task wrapper(type: Wrapper) { gradleVersion = '0.9'
}
After such an execution you find the following new or updated files in your project directory (in case the default configuration of the wrapper task is used).
Example 54.2. Wrapper generated files
Build layout
simple/ gradlew gradlew.bat
gradle/wrapper/ gradle-wrapper.jar gradle-wrapper.properties
Page 323 of 343
All of these files should be submitted to your version control system. This only needs to be done once. After these files have been added to the project, the project should then be built with the added gradlew command. The gradlew command can be used exactly the same way as the gradle command.
If you want to switch to a new version of Gradle you don't need to rerun the wrapper task. It is goo enough to change the respective entry in the gradle-wrapper.properties file. But if there is for example an improvement in the gradle-wrapper functionality you need to regenerate the wrapper files.
54.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 where the wrapper files should be stored (within your project directory):
Example 54.3. Configuration of wrapper task
build.gradle
task wrapper(type: Wrapper) { gradleVersion = '0.9'
jarFile = 'wrapper/wrapper.jar'
}
Build layout
customized/ gradlew gradlew.bat wrapper/
wrapper.jar
wrapper.properties
You can specify the download URL of the wrapper distribution. You can also specify where the wrapper distribution 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.
For the details on how to configure the wrapper, see Wrapper
If you don't want any download to happen when your project is build viagradlew, simply add the Gradle distribution zip to your version control at the location specified by your wrapper configuration. Relative url is supported - you can specify a distribution file relative to the location of file.
If you build via the wrapper, any existing Gradle distribution installed on the machine is ignored.
Page 324 of 343