Файл: Gradle.pdf

Page 329 of 343

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