How do I customize the task name displayed in Gradle console output?

How can I customize how a task is ‘rendered’ in the output? For example, I want to change the output of ‘:build’.

There seems to be a special mechanism in Gradle to achieve this.

Can you give an example to illustrate, Etienne?

By default, the task name is rendered like this:

cmd$ gradle compileJava :compileJava UP-TO-DATE

I want the task name to be rendered like this:

cmd$ gradle compileJava :compileJava-sample-customization UP-TO-DATE

I’ve heard that there is some hook and custom logger to make this possible.

Hi Etienne,

you can use a custom build adapter in your build scripts:

gradle.useLogger(new MyBuildAdapter())
  class MyBuildAdapter extends BuildAdapter
                         implements TaskExecutionListener {
      public void beforeExecute(Task task) {
      public void afterExecute(Task task, TaskState state) {
  print "> ${} "
  println state.skipped ? state.skipMessage : " executed!"
          public void buildFinished(BuildResult result) {
        println 'build completed'

I don’t see an explicitly built in way of doing what you’re looking for. Here’s the line of investigation I followed:

The TaskExecutionLogger is responsible for setting the loggingHeader on the ProgressLogger, and it’s not open for extension:

public void beforeExecute(Task task) {
      private String getDisplayName(Task task) { ... }

You could consider providing an alternate implementation for TaskExecutionListener, however this is setup by DefaultGradleLauncherFactory with a call to ListenerManager.useLogger.

However, I don’t think the TopLevelBuildServiceRegistry is exposed to the build script in order to tweak this.

Another avenue which looks equally hairy is ProgressLogEventGenerator and OutputEventRenderer which create structured log text and render them, respectively.

But the base question is really: why do you want to do this? :slight_smile:

As mentioned in my previous post, gradle explicitly supports this. I can imagine a bunch of reasons. For example think of an ci server plugin, that wants to convert the default output to an output, that is easier parseable/adds html highlight etc.

You don’t want to extend BuildAdapter here, as you’re also overriding the logging for BuildListener, which means you’ll override the build summary that is written at the end of the build.

Now I’m confused, Adam. You said extending the BuildAdapter is not ideal, but you’re pointing to the docs that do the same thing - am I overseeing the difference or is there none…?

The example in the docs customises 2 things: how the task names are logged, and how the build progress is logged. It does this by implementing both TaskExecutionListener and BuildListener (indirectly through BuildAdapter).

You just want to customise how the task names are logged, so you should just implement TaskExecutionListener.

Got it. Thanks, Adam.

This is possible, if a little awkward. See