Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Gradle log


May 25, 2021 Gradle


Table of contents


Log

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

Select a log level

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.

Write your own log messages

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')  

Logs are logged using external tools and libraries

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.

Change the Gradle log

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.

  • BuildListener
  • ProjectEvaluationListener
  • TaskExecutionGraphListener
  • TaskExecutionListener
  • TaskActionListener