Example 52.7. A build script with external dependencies
build.gradle
import org.apache.commons.codec.binary.Base64
buildscript { repositories {
mavenCentral()
}
dependencies {
classpath group: 'commons-codec', name: 'commons-codec', version: '1.2
}
}
task encode << {
def byte[] encodedString = new Base64().encode('hello world\n'.getBytes()) println new String(encodedString)
}
Output of gradle -q encode
> gradle -q encode aGVsbG8gd29ybGQK
For multi-project builds, the dependencies declared in the a project's build script, are available t the build scripts of all sub-projects.
52.6. Ant optional dependencies
For reasons we don't fully understand yet, external dependencies are not picked up by Ant optional tasks. But you can easily do it in another way.
Page 317 of 343
Example 52.8. Ant optional dependencies
build.gradle
configurations { ftpAntTask
}
dependencies { ftpAntTask("org.apache.ant:ant-commons-net:1.8.2") {
module("commons-net:commons-net:1.4.1") { dependencies "oro:oro:2.0.8:jar"
}
}
}
task ftp << { ant {
taskdef(name: 'ftp',
classname: 'org.apache.tools.ant.taskdefs.optional.net.FTP', classpath: configurations.ftpAntTask.asPath)
ftp(server: "ftp.apache.org", userid: "anonymous", password: "me@myorg fileset(dir: "htdocs/manual")
}
}
}
This is also nice example for the usage of client modules. The pom.xml in maven central for the ant-commons-net task does not provide the right information for this use case.
52.7. Summary
Gradle offers you a variety of ways of organizing your build logic. You can choose what is right for your domain and find the right balance between unnecessary indirections, and avoiding redundancy and a hard to maintain code base. It is our experience that even very complex custom build logic is rarely shared between different builds. Other build tools enforce a separation of this build logic into a separate project. Gradle spares you this unnecessary overhead and indirection.
[23] Which might range from a single class to something very complex.
[24] In fact, we think this is anyway the nicer solution. Only if your buildscript and Ant's option task need the same library you would have to define it two times. In such a case it would be nice, if Ant's optional task would automatically pickup the classpath defined in thegradesettings.
Page 318 of 343
53
Initialization Scripts
Gradle provides a powerful mechanism to allow customizing the build based on the current environment. This mechanism also supports tools that wish to integrate with Gradle.
53.1. Basic usage
Initialization scripts (a.k.a. init scripts) are similar to other scripts in Gradle. These scripts, however, are run before the build starts. Here are several possible uses:
Set up enterprise-wide configuration, such as where to find custom plugins.
Set up properties based on the current environment, such as a developer's machine vs. continuous integration server.
Supply personal information about the user that is required by the build, such as repository or database authentication credentials.
Define machine specific details, such as where JDKs are installed.
Register build listeners. External tools that wish to listen to Gradle events might find this useful.
Register build loggers. You might wish to customise how Gradle logs the events that it generates.
One main limitation of init scripts is that they cannot access classes in the buildSrc project (see Section 52.3, “Build sources in thebuildSrc project” for details of this feature).
53.2. Using an init script
There are several ways to use an init script:
Specify a file on the command line. The command line option is -I or --init-script followed by the path to the script. The command line option can appear more than once, each time adding another init script.
Put a file called init.gradle in the USER_HOME/.gradle/ directory.
Page 319 of 343
Put a file that ends with .gradle in the USER_HOME/.gradle/init.d/ directory.
Put a file that ends with .gradle in the GRADLE_HOME/init.d/ directory, in the Gradle distribution. This allows you to package up a custom Gradle distribution containing some custom build logic and plugins. You can combine this with the Gradle wrapper as a way to make custom logic available to all builds in your enterprise.
If more than one init script is found they will all be executed, in the order specified above. Scripts in a given directory are executed in alphabetical order. This allows, for example, a tool to specify an init script on the command line and the user to put one in their home directory for defining the environment and both scripts will run when Gradle is executed.
53.3. Writing an init script
Similar to a Gradle build script, an init script is a groovy script. Each init script has a Gradle instance associated with it. Any property reference and method call in the init script will delegate to this Gradle instance.
Each init script also implements the Script interface.
53.3.1. Configuring projects from an init script
You can use an init script to configure the projects in the build. This works in a similar way to configuring projects in a multi-project build. The following sample shows how to perform extra configuration from an init script before the projects are evaluated. This sample uses this feature to configure an extra repository to be used only for certain environments.
Page 320 of 343