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
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.:
interfaceKoverProjectExtension {
val reports:KoverReportsConfigfunreports(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:
interfaceKoverProjectExtension {
val variants:PolymorphicDomainObjectContainer<KoverVariant>
}
interfaceKoverVariantsContainer : PolymorphicDomainObjectContainer<KoverVariant> {
val provided:NamedDomainObjectCollection<KoverProvidedVariant>
val custom:NamedDomainObjectCollection<KoverCustomVariant>
val total:KoverTotalVariant
}
// minimal DSL interfacesinterfaceKoverVariant: NamedinterfaceKoverProvidedVariant : KoverVariantinterfaceKoverCustomVariant : KoverVariantinterfaceKoverTotalVariant : KoverVariant
This could be a basic implementation for KoverVariantsContainer:
internalabstractclassKoverVariantsContainerImpl @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)
}) {
overrideval provided = withType<KoverProvidedVariant>()
overrideval custom = withType<KoverCustomVariant>()
overrideval total = objects
.newInstance<KoverTotalVariant>("total")
.also(::add)
internalfunaddProvidedVariant(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:
kover.reports.doSomething() // and kover.reports { doSomething() }
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:The text was updated successfully, but these errors were encountered: