@kyle I think that this should probably use

.all

, not

.configureEach

. Let me explain why. https://github.com/gradle/gradle/blob/master/subprojects/jacoco/src/main/java/org/gradle/testing/jacoco/plugins/JacocoReportAggregationPlugin.java#L98

🙈

it's arguable if our plugin should use

create

instead of register (it probably should), but from the plugin point of view, I think semantically, what you want is really: for each report in the model, register a task. So the model must be eager, but the tasks must be lazy.

Fun!

This is a known situation, where we have lazy methods available on containers which aren’t lazy. Like the publication model, for example.

this is the commit which fixed it: https://github.com/micronaut-projects/micronaut-build/pull/274/commits/fbfe61ef2270fb6118881726ae3b39cc8de1b28e (note this is a PR, the bug was in a PR)

I’d argue that plugins, core and otherwise, should use

register

and there should be a consumer at a definite point in time. Making everything eager now (core and plugins) goes against the configuration avoidance discipline we’ve been working to establish.

According issue for reference: https://github.com/gradle/gradle/issues/19955

Thanks for posting the link to the issue, Björn. This should be coming in 7.4.1.

yeah I'm a bit puzzled about what is supposed to trigger the consumption 🙂

The core problem (I can talk at length with experience with Nokee and the whole native ecosystem in Gradle, software model included) is discoverability. Everything is fine regarding laziness, but Gradle doesn’t know which container produce which domain objects. You can go even further to say which elements produce other domain objects. Saying that some domain container are eager while others aren’t is extremely confusing but also goes around the core issue because some situation may create a cascading effect which blow up the configuration time. Feel free to reach out, Sterling and I had a lot of discussion around similar issues.

Hi Daniel. Yes, Sterling and I were just talking about you and the native ecosystem w.r.t. both this and adding more flexibility to dependency resolution. We’ll be in touch.