toolingApi/idea |
An application which uses the tooling API to extract |
|
information needed by IntelliJ IDEA. |
webApplication/customised |
Web application with customized WAR contents. |
webApplication/quickstart |
Web application quickstart project |
A.1. Sample customBuildLanguage
This sample demonstrates how to add some custom elements to the build DSL. It also demonstrates the use of custom plug-ins to organize build logic.
The build is composed of 2 types of projects. The first type of project represents a product, and the second represents a product module. Each product includes one or more product modules, and each product module may be included in multiple products. That is, there is a many-to-many relationship between these products and product modules. For each product, the build produces a ZIP containing the runtime classpath for each product module included in the product. The ZIP also contains some product-specific files.
The custom elements can be seen in the build script for the product projects (for example, basicE
). Notice that the build script uses the product { } element. This is a custom element.
The build scripts of each project contain only declarative elements. The bulk of the work is done by 2 custom plug-ins found in buildSrc/src/main/groovy.
A.2. Sample customDistribution
This sample demonstrates how to create a custom Gradle distribution and use it with the Gradle wrapper.
This sample contains the following projects:
The plugin directory contains the project that implements a custom plugin, and bundles the plugin into a custom Gradle distribution.
The consumer directory contains the project that uses the custom distribution.
A.3. Sample customPlugin
A set of projects that show how to implement, test, publish and use a custom plugin and task.
This sample contains the following projects:
The plugin directory contains the project that implements and publishes the plugin.
The consumer directory contains the project that uses the plugin.
Page 330 of 343
A.4. Sample java/multiproject
This sample demonstrates how an application can be composed using multiple Java projects.
This build creates a client-server application which is distributed as 2 archives. First, there is a client ZIP which includes an API JAR, which a 3rd party application would compile against, and a client runtime. Then, there is a server WAR which provides a web service.
Page 331 of 343
B
Potential Traps
B.1. Groovy script variables
For Gradle users it is important to understand how Groovy deals with script variables. Groovy has two types of script variables. One with a local scope and one with a script wide scope.
Page 332 of 343
Example B.1. Variables scope: local and script wide
scope.groovy
String localScope1 = 'localScope1' def localScope2 = 'localScope2' scriptScope = 'scriptScope'
println localScope1 println localScope2 println scriptScope
closure = {
println localScope1 println localScope2 println scriptScope
}
def method() {
try {localScope1} catch(MissingPropertyException e) {println 'localScope1N try {localScope2} catch(MissingPropertyException e) {println 'localScope2N println scriptScope
}
closure.call()
method()
Output of gradle
> gradle localScope1 localScope2 scriptScope localScope1 localScope2 scriptScope
localScope1NotAvailable
localScope2NotAvailable scriptScope
Variables which are declared with a type modifier are visible within closures but not visible within methods. This is a heavily discussed behavior in the Groovy community.
B.2. Configuration and execution phase
It is important to keep in mind that Gradle has a distinct configuration and execution phase (see Chapter 48, The Build Lifecycle).
Page 333 of 343
Example B.2. Distinct configuration and execution phase build.gradle
classesDir = file('build/classes') classesDir.mkdirs()
task clean(type: Delete) { delete 'build'
}
task compile(dependsOn: 'clean') << { if (!classesDir.isDirectory()) {
println 'The class directory does not exist. I can not operate' // do something
}
// do something
}
Output of gradle -q compile
> gradle -q compile
The class directory does not exist. I can not operate
As the creation of the directory happens during the configuration phase, the clean task removes the directory during the execution phase.
[ 25 ] One of those discussions can be found here: http://groovy.329449.n5.nabble.com/script-scoping-question-td355887.html
Page 334 of 343
C
Gradle Command Line
The gradle command has the following usage:
gradle [option...] [task...]
The command-line options available for the gradle command are listed below:
-?, -h, --help
Shows a help message.
-a, --no-rebuild
Do not rebuild project dependencies.
--all
Shows additional detail in the task listing. See Section 11.5.2, “Listing tasks”.
-b, --build-file
Specifies the build file. See Section 11.4, “Selecting which build to execute”.
-c, --settings-file
Specifies the settings file.
--continue
Continues task execution after a task failure.
-D, --system-prop
Sets a system property of the JVM, for example -Dmyprop=myvalue. See Section 14.2, “Gradle properties and system properties”.
-d, --debug
Log in debug mode (includes normal stacktrace). See Chapter 19, Logging.
-g, --gradle-user-home
Specifies the Gradle user home directory. The default is the .gradle directory in the user' home directory.
--gui
Launches the Gradle GUI. See Chapter 12, Using the Gradle Graphical User Interface.
Page 335 of 343
-I, --init-script
Specifies an initialization script. See Chapter 53, Initialization Scripts.
-i, --info
Set log level to info. See Chapter 19, Logging.
-m, --dry-run
Runs the build with all task actions disabled. See Section 11.6, “Dry Run”.
--no-color
Do not use color in the console output.
--offline
Specifies that the build should operate without accessing network resources. See Section 43.8.2, “Command line options to override caching”.
-P, --project-prop
Sets a project property of the root project, for example -Pmyprop=myvalue. See Section 14.2, “Gradle properties and system properties”.
-p, --project-dir
Specifies the start directory for Gradle. Defaults to current directory. See Section 11.4, “Selecting which build to execute”.
--profile
Profiles build execution time and generates a report in the buildDir/reports/profile directory. See Section 11.5.5, “Profiling a build”.
--project-cache-dir
Specifies the project-specific cache directory. Default value is .gradle in the root project directory. See Section 14.6, “Caching”.
-q, --quiet
Log errors only. See Chapter 19, Logging.
--recompile-scripts
Specifies that cached build scripts are skipped and forced to be recompiled. See Section 14.6, “Caching”.
--refresh-dependencies
Refresh the state of dependencies. See Section 43.8.2, “Command line options to overrid caching”.
--rerun-tasks
Specifies that any task optimization is ignored.
-S, --full-stacktrace
Print out the full (very verbose) stacktrace for any exceptions. See Chapter 19, Logging.
-s, --stacktrace
Page 336 of 343