-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add possibility of lazy configuration of Kover extensions #410
Labels
Comments
shanshin
added
Feature
Feature request issue type
S: untriaged
Status: issue reported but unprocessed
labels
Jun 14, 2023
shanshin
added
S: in progress
Status: implementing or design in process
and removed
S: untriaged
Status: issue reported but unprocessed
labels
Jun 27, 2023
Closed
shanshin
added a commit
that referenced
this issue
Feb 19, 2024
- 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 #461 Resolves #410 Resolves #462 Resolves #463 Resolves #338
shanshin
added
S: ready for release
Status: merged in the main branch
and removed
S: in progress
Status: implementing or design in process
labels
Feb 20, 2024
Implemented in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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: