Redesign the concept of default reports

[Sergey Shanshin]

Motivation

At the moment, the concept of default reports is not obvious to the user

The word default/defaults is too ambiguous

Code like

koverReport {
    defaults {
        filters {
            // some filters
        }
    }
}

the newbie user can be read as “default filters for all reports”.
Without reading the documentation, it is not clear what exactly the defaults block is used for.

Default reports solve too many things

Default reports both generate reports only for classes from JVM targets, and also used in Android projects to get a report on few or all of the build variants - by using mergeWith(“variantName”).

default reports behave differently for different project types

Calling the koverHtmlReport task for a JVM project leads to the generation of a report on all classes from the project.
Calling the koverHtmlReport task for a Android project leads will not generate anything until the user explicitly writes koverReport { defaults { mergeWith("release") } } .
Calling the koverHtmlReport task for a MPP JVM+Android project generates a report only for classes and tests of the JVM target, but not for Android build variants

Solution

• remove the default reports concept
• clearly describe in the documentation the concept of the report variant
• add report tasks (total reports) that will generate a reports for all classes of the build with the same names as the default reports now have (e.g. koverXmlReport, koverHtmlReport)

Total reports

Total report - this is a report on all classes and test tasks that are in a specific Gradle project.

Total reports does not have its own report variant, in fact it is a combined report on all the report variants available in the project.
Total coverage reports are always existed and can be called in any type of project, even if none of the Kotlin plugins are used. This is convenient when there are no sources in the root project, but the options from kover(project(":foo")) are taken dependencies and generated a merged report for all subprojects.

config example

koverReport {
    total {
        filters {}
        xml {}
        html {}
        binary {}
        log {}
        verify {}
    }
}

[Sergey Shanshin]

Implemented in 0.8.0-Beta.
This is not a production ready release, the plugin DSL is experimental and can be changed after receiving feedback.