From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

I did something similar with spotbugs tasks.
It was a while back with Gradle 5.6.2, but back then I also resorted to `tasks.withType&lt;...&gt;().all { ... }` which effectively is the same as `tasks.withType&lt;...&gt; { ... }`.
I don't think anything changed since then.

Yeah that’s effectively what we’re doing right now. Hmm

I almost want a `whenTaskRegistered` callback where the task is still TaskProvider&lt;TheOtherTask&gt;, in a context where I can call `registerTask`. So the other task doesn’t have to get registered, and neither does mine if it’s not called.

Welcome to the club. :smile:
I think there is even an issue for it somewhere, but I'm not finding it right now.

What you maybe could do is to not handle the `JacocoReport` tasks, but derive them from where they are registered from. You will not get custom `JacocoReport` tasks covered, but for the standard tasks it should work.

By derive them do you mean check out the jacoco plugin and gradle and effectively follow the same logic?

```tasks.addRule("after jacoco") {
    val baseName = removeSuffix("JacocoReportFinisher")
    if (equals(baseName)) return@addRule
    tasks.register(this) {
        dependsOn(baseName)
        doLast { ... }
    }
}
tasks.withType&lt;JacocoReport&gt;().configureEach {
    finalizedBy("${name}JacocoReportFinisher")
}```
completely untested but something along those lines

Hm, interesting idea. I tend to forget task rules as I try to avoid them.

what sort of task did you want to register <@UT8DZBKHV>? Is it something that can be done with a `doLast {}` block, and dynamically registering inputs/outputs?

Perhaps? This is a classic example of “we use plugin x, plugin x doesn’t support new gradle feature y, go fix it”

In this case I’m trying to retrofit modern gradle-isms onto a plugin that still supports gradle 5

Namely I’m trying to replace with line <https://gitlab.com/barfuin/gradle-jacoco-log/-/blob/master/src/main/java/org/barfuin/gradle/jacocolog/JacocoLogPlugin.java#L51> with something more modern

These retrofits always beg the question tho, should I try to keep what’s there as intact as possible, or maybe rethink the way the plugin is written.

I think dynamically registering new tasks based on other tasks might be too difficult, but it should be possible to collect the JaCoCo report files created by the JaCoCo tasks, and then register a single task that consumes them

build_gradle_kts.kt

Explicit paths and `dependsOn`s :fearful:

Perhaps I should look into the
```jacoco-report-aggregation```
plugin, see how that works.