does compileScoverageScala need to depend on compileScoverageScala of its dependencies?

[dsilvasc]

The compileScoverageScala task depends on compileScoverageScala for all its dependencies:

https://github.com/JozoVilcek/gradle-scoverage/blame/c5870c9b924bb5c46c343c2732f65bfde37aa562/src/main/groovy/org/scoverage/ScoveragePlugin.groovy#L159

Is this necessary? The comments there say it's for the case where someone builds without compileScala tasks per the readme:

https://github.com/JozoVilcek/gradle-scoverage/blob/c5870c9b924bb5c46c343c2732f65bfde37aa562/README.md#run-without-normal-compilation

Would it be feasible for the compileScoverageScala task to only depend on other compileScoverageScala tasks when the compileScala tasks it depends on are disabled?

That way, when running tests for a subset of a project (for example, the gradle subprojects involving files that changed in a pull request), only the subprojects being tested would be compiled with instrumentation, and their dependencies would run their normal compile tasks.

[maiflai]

Potentially - I've been looking infrequently at updating the dependencies such that it works properly with current Gradle versions.

My personal preference is that code coverage collection is restricted to the tests of the specific module, but I think I'm in the minority here.

Better control would be good.

[eyalroth]

Would it be feasible for the compileScoverageScala task to only depend on other compileScoverageScala tasks when the compileScala tasks it depends on are disabled?

It might. I don't remember exactly, but I do recall some issues with trying to set dependencies based on user input, such as disabling tasks via configuration (enabled = false) or command line (-x). This was in Gradle 6 though, so perhaps something has changed to make this possible.