14.2.1. Checking for project properties

You can access a project property in your build script simply by using its name as you would use a variable. In case this property does not exists, an exception is thrown and the build fails. If your build script relies on optional properties the user might set for example in a gradle.properties file, you need to check for existence before you can access them. You can do this by using the method hasProperty('propertyName') which returns true or false.

14.3. Configuring the project using an external build script

You can configure the current project using an external build script. All of the Gradle build language is available in the external script. You can even apply other scripts from the external script.

Example 14.3. Configuring the project using an external build script

build.gradle

apply from: 'other.gradle'

other.gradle

println "configuring $project" task hello << {

println 'hello from other script'

}

Output of gradle -q hello

> gradle -q hello

configuring root project 'configureProjectUsingScript' hello from other script

14.4. Configuring arbitrary objects

You can configure arbitrary objects in the following very readable way.

Page 74 of 343

Example 14.4. Configuring arbitrary objects build.gradle

task configure << {

pos = configure(new java.text.FieldPosition(10)) { beginIndex = 1

endIndex = 5

}

println pos.beginIndex println pos.endIndex

}

Output of gradle -q configure

> gradle -q configure 1 5

14.5. Configuring arbitrary objects using an external script

You can also configure arbitrary objects using an external script.

Example 14.5. Configuring arbitrary objects using a script

build.gradle

task configure << {

pos = new java.text.FieldPosition(10) // Apply the script

apply from: 'other.gradle', to: pos println pos.beginIndex

println pos.endIndex

}

other.gradle

beginIndex = 1; endIndex = 5;

Output of gradle -q configure

> gradle -q configure 1 5

Page 75 of 343

14.6. Caching

To improve responsiveness Gradle caches all compiled scripts by default. This includes all build scripts, initialization scripts, and other scripts. The first time you run a build for a project, Gradle creates a .gradle directory in which it puts the compiled script. The next time you run this build, Gradle uses the compiled script, if the script has not changed since it was compiled. Otherwise the script gets compiled and the new version is stored in the cache. If you run Gradle with the --recompile-scripts option, the cached script is discarded and the script is compiled and stored in the cache. This way you can force Gradle to rebuild the cache.

[5] Teamcity or Bamboo are for example CI servers which offer this functionality.

Page 76 of 343

15

The Build Environment

15.1. Configuring the build environment via gradle.properties

Gradle provides several options that make it easy to configure the Java process that will be used to execute your build. While it's possible to configure these in your local environment vi GRADLE_OPTS or JAVA_OPTS, certain settings like jvm memory settings, java home, daemon on/off can be more useful if they can versioned with the project in your VCS so that the entire team can work with consistent environment. Setting up a consistent environment for your build is as simple as placing those settings into a gradle.properties file. The configuration is applied in following order (in case an option is configured in multiple locations the last one wins):

from gradle.properties located in project build dir.

from gradle.properties located in gradle user home.

from system properties, e.g. when -Dsome.property is used in the command line.

The following properties can be used to configure the Gradle build environment:

org.gradle.daemon

When set to true the Gradle daemon is to run the build. For local developer builds this is our favorite property. The developer environment is optimized for speed and feedback so we nearly always run Gradle jobs with the daemon. We don't run CI builds with the daemon (i.e a long running process) as the CI environment is optimized for consistency and reliability.

org.gradle.java.home

Specifies the java home for the Gradle build process. The value can be set to either jdk or j location, however, depending on what does your build do, jdk is safer. Reasonable default is used if the setting is unspecified.

org.gradle.jvmargs

Specifies the jvmargs used for the daemon process. The setting is particularly useful for tweaking memory settings. At the moment the default settings are pretty generous with regards to memory.

Page 77 of 343