You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is less flexible, because we must constantly remember to add new subprojects, as well as if the values differ for a large number of projects, then there will be a lot of lists and if .
In such cases, an project extension is added through which you can configure the behavior of the plugin.
The convention plugin is applied before the project is evaluated.
In logs will be:
read value
write value
Accordingly, it is not possible in the current form to configure Kover through the convention plugin.
afterEvaluate is often used to circumvent this limitation, which in many cases is performed in an unpredictable order.
This problem goes away if the Kaver properties are of the Property<...> type, and not of the primitive type:
- blocks kover and koverReports are merged
- added possibility of lazy configuration of Kover extensions
- removed the concept of default reports
- added the ability to create custom report variants
- Created interfaces for Kover tasks
Resolves#461Resolves#410Resolves#462Resolves#463Resolves#338
Motivation
In order not to write the same boilerplate configuration code, it can be placed in a convention plugin.
Since the expected coverage may vary for each subproject, so if you put this code in a convention plugin, you will have to write something like this
This is less flexible, because we must constantly remember to add new subprojects, as well as if the values differ for a large number of projects, then there will be a lot of lists and if .
In such cases, an project extension is added through which you can configure the behavior of the plugin.
in the user project project itself
The convention plugin is applied before the project is evaluated.
In logs will be:
Accordingly, it is not possible in the current form to configure Kover through the convention plugin.
afterEvaluate is often used to circumvent this limitation, which in many cases is performed in an unpredictable order.
This problem goes away if the Kaver properties are of the Property<...> type, and not of the primitive type:
example project and issue.
Solution
Replace all configurable values of the primitive type with wrappers-providers over this type.
Example of new DSL
The text was updated successfully, but these errors were encountered: