Remove Implicit Dependency warning from Gradle output

Question

I've got a generic task in my Gradle build that copies some configuration files to be included in the build, but aren't required for compiling or anything else (they're used at runtime). Basically:

val copyConfiguration by tasks.registering(Copy::class) {
    from("${projectDir}/configuration")
    into("${buildDir}/")
}

This however leads to an issue in every other task as I now get the Gradle warning about how the tasks use this output without declaring an explicit or implicit dependency

Execution optimizations have been disabled for task ':jacocoTestCoverageVerification' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '...'. Reason: Task ':jacocoTestCoverageVerification' uses this output of task ':copyConfiguration' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.

Now this is only a warning, and the build succeeds, and my service starts up and runs fine. But it does clog my output making it harder to find the line where something went wrong and is in general an eyesore. I'd like to somehow remove that warning. I saw (from the wiki) that the general solution for this is to write an explicit dependency in the task definition, but since this is happening for every task (from compile, to test, to ktlint, to jacoco, etc.) I don't really want to do that.

Is there an alternative, like an anti-dependency, wherein I can tell Gradle that it shouldn't care about the output of the :copyConfiguration task?

Answer 1

I had a similar issue and funny that it started with a task related to Jacoco. I documented a solution here https://discuss.gradle.org/t/task-a-uses-this-output-of-task-b-without-declaring-an-explicit-or-implicit-dependency/42896

In short, what worked for me was to get the location with the problem using the task properties, e.g. getOutputs. Hope this helps.