<@U02DGQN2WL9> I think that this should probably u...
# plugin-development
we found a "funny" bug in our Micronaut build plugins, because they were using
, which is lazy.
So basically, no reports were ever created, because no one was ever eagerly creating them
so the jacoco aggregate report task was never created...
it's arguable if our plugin should use
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.
This is a known situation, where we have lazy methods available on containers which aren’t lazy. Like the publication model, for example.
Let’s talk more about how this didn’t work as expected for Micronaut.
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
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.
👍 2
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.
👌 1
In the meantime, Rodrigo let’s talk about how to make non-lazy containers… lazy. 🙂
❤️ 1
👌 2
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.
👍 1