May 25, 2021 Gradle
Logs are the primary interface for building tools. I f there are too many logs, real warnings and problems can easily be hidden. O n the other hand, if something goes wrong, you need to find out about it. G radle defines six log levels, as shown in Table 18.1, Log Levels. T here are two Gradle-specific log levels in addition to those that you might see through. T he two levels are QUIET and LIFECYCLE. This log level that follows is used by default to report build progress.
Table 18.1. The log level
Level | For |
ERROR | The error message |
QUIET | Important information messages |
WARNING | Warning message |
LIFECYCLE | Progress information message |
INFO | Informational messages |
DEBUG | Debug the message |
You can select different log levels using the command line switch shown in Table 18.2, The Command Line Options at log level. In Table 18.3, The Command Line Options for Stack Tracking, you can see the command line switches that affect the stack trace log.
Table 18.2. The command line option at the log level
Options | The output log level |
There are no log options | LIFECYCLE and higher |
--quiet
|
QUIET and higher |
--info
|
INFO and higher |
--debug
|
DEBUG and higher |
Table 18.3. The command line option for stack tracking
Options | Significance |
There are no stack tracking options |
Build errors, such as compilation errors, when no stack traces are printed to the console. S
tack traces are printed only in the event of an internal exception.
If you
DEBUG
log level, the intercepted stack trace information is always output.
|
--stacktrace
|
Output truncated stack trace. W e recommend using this option instead of printing the entire stack of tracking information. G roovy's full stack traces are lengthy (due to their potential dynamic calling mechanism, however, they usually don't contain information about what went wrong in your code).) ) |
--full-stacktrace
|
Print tracking information for the entire stack. |
In building files, an easy way to print logs is to write messages to standard output. Gradle redirects everything written to the standard output to the QUIET level of its log system.
Write logs using standard output
build.gradle
println 'A message which is logged at QUIET level'
Gradle also provides a logger property to the build script, which is a Loger instance. T he interface extends from the Logger interface of SLF4J and adds several Gradle-only methods. Here's an example of how to use it in a build script:
Write 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 to Gradle's log system (such as a class in the buildSrc directory) through other classes used in the build script. J ust use one SLF4J logger object. You can use this logger in the build script in the same way as the built-in logger.
Use 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')
Gradle uses Ant and Ivy internally. T hey all have their own log systems. G radle redirects its log output to Gradle's log system. T he log level from Ant/Ivy to Gradle is a one-to-one mapping, except for the TRACE level of Ant/Ivy, which maps to the DEBUG level of Gradle. This means that by default, the Gradle log level will not display any Ant/Ivy output unless it is an error or warning message.
There are many tools that are still using standard output logging. B y default, Gradle redirects the standard output to the QUET log level and rewrites the standard error output to the ERROR level. T his behavior is configurable. The Project object provides a LoggingManager that allows you to modify the log level of standard output and error redirection when calculating build scripts.
Configure standard output capture
build.gradle
logging.captureStandardOutput LogLevel.INFO
println 'A message which is logged at INFO level'
Task also provides a LoggingManager for changing the log level of standard output or errors during task execution.
Configure standard output capture for tasks
build.gradle
task logInfo {
logging.captureStandardOutput LogLevel.INFO
doFirst {
println 'A task message which is logged at INFO level'
}
}
Gradle also provides integration of log tools for Java Util Logging, Jakarta Commons Loggings, and Log4j. Any log messages that you generate that are output using these logging tools are redirected to Gradle's log system.
You can replace Gradle's in large numbers with your own logging UI. Y ou can do this, for example, if you want to customize the UI in some way -- to output more or less information-- or to modify the log format you can replace the logging with the Gradle.useLogger() method. I t can be accessed in build scripts, or init scripts, or through embedded APIs. N ote that it disables the default output of Gradle completely. The following is an example of modifying log printing for task execution and build completion in an init script.
Customize the Gradle log
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'
if (result.failure != null) {
result.failure.printStackTrace()
}
}
}
The output of the 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. W hen you register a logger, you can only replace the logging of the interfaces it implements. Logging for other interfaces is constant.