What is your use-case and why do you need this feature?
I recently put focus into this project while I was researching it for a potential replacement on JaCoCo.
While exploring 0.8.0-Beta2 usage and internals (source code), I've identified some pain points in the current experimental DSL, that IMHO should be addressed by leveraging Gradle-managed objects, like NamedDomainObjectContainer and its variants.
I didn't scan fully what the project has to offer, like filtering, etc. So you may consider this as partial feedback.
Describe the solution you'd like
Child closures in DSL
The main kover: KoverProjectExtension extension has several child closures, like reports: KoverReportsConfig.
These closures can only be accessed by calling a method (i.e. kover.reports { }).
As my current understanding of Gradle's patterns, child closures should be accessible by property or method closure, so the following two syntaxes should be valid and equivalent:
kover.reports.doSomething()
// and
kover.reports {
doSomething()
}
This can easily be achieved by changing a bit the DSL object definition, i.e.:
interface KoverProjectExtension {
val reports: KoverReportsConfig
fun reports(action: Action<KoverReportsConfig>) = action.configure(reports)
}
kover.variants DSL
Kover currently supports (as far I noted) three types of variants: provided, customer, and total
It would be nice if you iterate the DSL to be able to access all declared variants with a NamedDomainObjectSet (at least), or even better, use a PolymorphicDomainObjectContainer to also use Gradle's standard API for creating them.
For instance, having:
interface KoverProjectExtension {
val variants: PolymorphicDomainObjectContainer<KoverVariant>
}
interface KoverVariantsContainer : PolymorphicDomainObjectContainer<KoverVariant> {
val provided: NamedDomainObjectCollection<KoverProvidedVariant>
val custom: NamedDomainObjectCollection<KoverCustomVariant>
val total: KoverTotalVariant
}
// minimal DSL interfaces
interface KoverVariant: Named
interface KoverProvidedVariant : KoverVariant
interface KoverCustomVariant : KoverVariant
interface KoverTotalVariant : KoverVariant
This could be a basic implementation for KoverVariantsContainer:
internal abstract class KoverVariantsContainerImpl @Inject constructor(
objects: ObjectFactory,
) : KoverVariantsContainer,
PolymorphicDomainObjectContainer<KoverVariant> by (objects.polymorphicDomainObjectContainer(KoverVariant::class).apply {
// only `KoverCustomVariant`s can be registered through DSL
registerBinding(KoverCustomVariant::class.java, KoverCustomVariant::class.java)
}) {
override val provided = withType<KoverProvidedVariant>()
override val custom = withType<KoverCustomVariant>()
override val total = objects
.newInstance<KoverTotalVariant>("total")
.also(::add)
internal fun addProvidedVariant(name: String, action: Action<KoverProvidedVariant>) = objects
.newInstance<KoverProvidedVariant>(name)
.also(action::execute)
.also(::add)
}
You could have a richer DSL, supporting many use cases out of the box:
What is your use-case and why do you need this feature?
I recently put focus into this project while I was researching it for a potential replacement on JaCoCo.
While exploring
0.8.0-Beta2
usage and internals (source code), I've identified some pain points in the current experimental DSL, that IMHO should be addressed by leveraging Gradle-managed objects, likeNamedDomainObjectContainer
and its variants.I didn't scan fully what the project has to offer, like
filtering
, etc. So you may consider this as partial feedback.Describe the solution you'd like
Child closures in DSL
The main
kover: KoverProjectExtension
extension has several child closures, likereports: KoverReportsConfig
.These closures can only be accessed by calling a method (i.e.
kover.reports { }
).As my current understanding of Gradle's patterns, child closures should be accessible by property or method closure, so the following two syntaxes should be valid and equivalent:
This can easily be achieved by changing a bit the DSL object definition, i.e.:
kover.variants
DSLKover currently supports (as far I noted) three types of variants:
provided
,customer
, andtotal
It would be nice if you iterate the DSL to be able to access all declared variants with a
NamedDomainObjectSet
(at least), or even better, use aPolymorphicDomainObjectContainer
to also use Gradle's standard API for creating them.For instance, having:
This could be a basic implementation for
KoverVariantsContainer
:You could have a richer DSL, supporting many use cases out of the box:
Iterating all variants in a hot collection
Configuring variant in a generic way
Imaging #599 is implemented in a way that
KoverVariant
now has anaggregate
property.We can target all
debug
variants at once with:Simplified plugin internal wiring
Currently, your plugin has some manual checks to prevent variants of different types from collishing with others with the same name.
If you centralize that into a root
NamedDomainObjectContainer
, this problem will be gone (less code).Later the plugin can just react on others, like Android one, and automatically register
provided
ones: