Файл: Gradle.pdf

Example 18.19. Creation of ZIP archive

build.gradle

apply plugin: 'java'

version = 1.0

task myZip(type: Zip) { from 'somedir'

}

println myZip.archiveName

println relativePath(myZip.destinationDir) println relativePath(myZip.archivePath)

Output of gradle -q myZip

> gradle -q myZip zipProject-1.0.zip build/distributions

build/distributions/zipProject-1.0.zip

This adds a Zip archive task with the name myZip which produces ZIP filezipProject-1.0.zip

. It is important to distinguish between the name of the archive task and the name of the archive generated by the archive task. The default name for archives can be changed with the archivesB project property. The name of the archive can also be changed at any time later on.

There are a number of properties which you can set on an archive task. These are listed below in Table 18.1, “Archive tasks - naming properties”.You can, for example, change the name of the archive:

Example 18.20. Configuration of archive task - custom archive name

build.gradle

apply plugin: 'java' version = 1.0

task myZip(type: Zip) { from 'somedir' baseName = 'customName'

}

println myZip.archiveName

Output of gradle -q myZip

> gradle -q myZip customName-1.0.zip

You can further customize the archive names:

Page 109 of 343

Example 18.21. Configuration of archive task - appendix & classifier

build.gradle

apply plugin: 'java' archivesBaseName = 'gradle' version = 1.0

task myZip(type: Zip) { appendix = 'wrapper' classifier = 'src' from 'somedir'

}

println myZip.archiveName

Output of gradle -q myZip

> gradle -q myZip gradle-wrapper-1.0-src.zip

Page 110 of 343

Table 18.1. Archive tasks - naming properties

Page 111 of 343

18.8.2. Sharing content between multiple archives

Using the Project.copySpec() method to share content between archives.

Often you will want to publish an archive, so that it is usable from another project. This process is described in Chapter 44, Publishing artifacts

Page 112 of 343

19

Logging

The log is the main 'UI' of a build tool. If it is too verbose, real warnings and problems are eas hidden by this. On the other hand you need the relevant information for figuring out if things have gone wrong. Gradle defines 6 log levels, as shown in Table 19.1, “Log levels”.There are two Gradle-specific log levels, in addition to the ones you might normally see. Those levels are QUIET and LIFECYCLE. The latter is the default, and is used to report build progress.

Table 19.1. Log levels

19.1. Choosing a log level

You can use the command line switches shown in Table 19.2, “Log level command-line options”to choose different log levels. In Table 19.3, “Stacktrace command-line options”you find the command line switches which affect stacktrace logging.

Table 19.2. Log level command-line options

Page 113 of 343

Table 19.3. Stacktrace command-line options

19.2. Writing your own log messages

A simple option for logging in your build file is to write messages to standard output. Gradle redirects anything written to standard output to it's logging system at theQUIET log level.

Example 19.1. Using stdout to write log messages

build.gradle

println 'A message which is logged at QUIET level'

Gradle also provides a logger property to a build script, which is an instance of Logger. This interface extends the SLF4J Logger interface and adds a few Gradle specific methods to it. Below is an example of how this is used in the build script:

Example 19.2. Writing your own log messages

build.gradle

logger.quiet('An info log message which is always logged.') logger.error('An error log message.')

logger.warn('A warning log message.') logger.lifecycle('A lifecycle info log message.') logger.info('An info log message.') logger.debug('A debug log message.') logger.trace('A trace log message.')

You can also hook into Gradle's logging system from within other classes used in the build (classe from the buildSrc directory for example). Simply use an SLF4J logger. You can use this logger the same way as you use the provided logger in the build script.

Page 114 of 343

Example 19.3. Using SLF4J to write log messages

build.gradle

import org.slf4j.Logger

import org.slf4j.LoggerFactory

Logger slf4jLogger = LoggerFactory.getLogger('some-logger') slf4jLogger.info('An info log message logged using SLF4j')

19.3. Logging from external tools and libraries

Internally, Gradle uses Ant and Ivy. Both have their own logging system. Gradle redirects their logging output into the Gradle logging system. There is a 1:1 mapping from the Ant/Ivy log levels to the Gradle log levels, except the Ant/Ivy TRACE log level, which is mapped to Gradle DEBUG log level. This means the default Gradle log level will not show any Ant/Ivy output unless it is an error or a warning.

There are many tools out there which still use standard output for logging. By default, Gradle redirects standard output to the QUIET log level and standard error to the ERROR level. This behavior is configurable. The project object provides a LoggingManager, which allows you to change the log levels that standard out or error are redirected to when your build script is evaluated.

Example 19.4. Configuring standard output capture

build.gradle

logging.captureStandardOutput LogLevel.INFO println 'A message which is logged at INFO level'

To change the log level for standard out or error during task execution, tasks also provide a

LoggingManager.

Example 19.5. Configuring standard output capture for a task

build.gradle

task logInfo {

logging.captureStandardOutput LogLevel.INFO doFirst {

println 'A task message which is logged at INFO level'

}

}

Gradle also provides integration with the Java Util Logging, Jakarta Commons Logging and Log4j logging toolkits. Any log messages which your build classes write using these logging toolkits will be redirected to Gradle's logging system.

Page 115 of 343

19.4. Changing what Gradle logs

You can replace much of Gradle's logging UI with your own. You might do this, for example, if yo want to customize the UI in some way - to log more or less information, or to change the formatting. You replace the logging using the Gradle.useLogger() method. This is accessible from a build script, or an init script, or via the embedding API. Below is an example init script which changes how task execution and build completion is logged.

Example 19.6. Customizing what Gradle logs

init.gradle

useLogger(new CustomEventLogger())

class CustomEventLogger extends BuildAdapter implements TaskExecutionListener

public void beforeExecute(Task task) { println "[$task.name]"

}

public void afterExecute(Task task, TaskState state) { println()

}

public void buildFinished(BuildResult result) { println 'build completed'

}

}

Output of gradle -I init.gradle build

> gradle -I init.gradle build [compile]

compiling source

[testCompile] compiling test source

[test]

running unit tests

[build]

build completed

Your logger can implement any of the listener interfaces listed below. When you register a logger, only the logging for the interfaces that it implements is replaced. Logging for the other interfaces is left untouched. You can find out more about the listener interfaces in Section 48.6, “Responding t the lifecycle in the build script”.

BuildListener

ProjectEvaluationListener

Page 116 of 343

TaskExecutionGraphListener

TaskExecutionListener

TaskActionListener

Page 117 of 343