Fail custom task and have IntelliJ jump to error location

Help/Discuss
1

If I compile a kotlin file using the build in compilation task in IntelliJ, and that file produces a compilation error, the following will happen:

  1. The build output will include a clickable line of text. Clicking it navigates to the location.
/my/project/code.kt:79:119: Expecting an expression
  1. IntelliJ will jump to the location of the first error it sees automatically
  2. The run tool window of intelliJ will list all such errors to the left of the console
  3. We can cycle through those errors, jumping to each as we cycle, using IntelliJ keyboard shortcuts.

I am seeking to make my custom gradle task produce errors with the same rich IDE support. So far, I have not been successful.

First, I tried to use the Problems API. I didn’t see anywhere a specification of what phase the Problems API could be used in, but so far I have only been able to successfully use it from the configuration phase. Here, I needed to use it from the task execution phase so I tried to @Inject it, but got an error about the service not being available. So I am assuming it is currently only intended for the configuration phase.

Next, I tried to just print the location. I essentially just did this in my custom task action:

throw GradleException("${file.path}:${it.line}:${it.col}: ${it.message}")

This was partially successful. It produced clickable output, and the IDE partially recognized that output as an error. Clicking the output in the console successfully navigated to the source location. However, some of the rich features are still missing:

  • The IDE did not automatically navigate to the first instance of my failure
  • The list of errors in the run tool window didn’t properly register my error as navigable apparently, because double clicking the error in the list (not in the console) doesn’t navigate to it. Also, the keyboard shortcuts to cycle through errors don’t work.

I suspect that Gradle+IntelliJ are using some special API to register navigable errors thrown at task execution time. Its also possible that IntelliJ could be looking for a specific format of error output in order to get rich support. Does anyone know?

2

Never tried that yet, but according to gradle/platforms/core-execution/workers/src/integTest/groovy/org/gradle/workers/internal/WorkerExecutorProblemsApiIntegrationTest.groovy at master · gradle/gradle · GitHub I’d say you can at least use the problems api from a work action.

1 Like
3

Thanks. I tried this and while I was now able to successfully get an instance of the Problems API, none of the problems I reported showed up in the console. Do you know if I should expect them to show in the console using Gradle version 8.10.2?

Here is a snippet from my work action:

getProblems()
.forNamespace("my.namespace")
.reporting {
    id("my.violation", "My Violation")
        .contextualLabel("Violation: ${it.ruleId}: ${it.detail}")
        .severity(Severity.ERROR)
        .lineInFileLocation(file.path, it.line, it.col)
}

I can confirm that this code did run. However, I see new output in the console from this, even at the info logging level.

4

I have no idea, never used it so far.
But I guess it is just for Problems API consumers and if you want it in the build output you have to additionally log it maybe?

5

According to the current docs for Problems:

Clients should expect that in future Gradle versions the reported problems will appear in console messages, reports, etc.

Thank you for sharing what you know. I guess we’ll wait and see how this develops.

1 Like
6

Ah, great.
Also, I find it strange that you can add problems at configuration time and in a work action, but not in a normal task implementation.
Unless this is listed in the docs as “not yet implemented but coming”, I’d suggest you check whether there is some issue reported about it and if not create one.
At least the docs should state that this is not possible / where it is possible, or made available to normal task actions too.
From gut feeling I’d say it is a bug if not documented otherwise. :man_shrugging: