This message was deleted.

Legit: https://melix.github.io/blog/2022/05/gradle-laziness.html 1st one and 2d are equivalent and eager. 3rd one is lazy.

First two are eager and cause each element to be realized and configured

…still hoping that, someday, Gradle will print deprecation warnings when using eager API calls…

for tasks, yes. For other containers, that's highly debatable.

Doesn't hurt to use it always though, does it?

sure it does: https://github.com/gradle/gradle/issues/19955

🤯

symptom of broader design issue - an API is exposed but not fully/properly implemented for those containers. 🤦

That makes it even more important to have proper guidance when to use what

What I tell everyone atm is: • Lazy API for

tasks

• Eager API for all other “Containers” (There is no gain in being lazy for e.g. SourceSets or Configurations and you may run into issues like the one linked above. I think in hindsight, despite good intentions, this was a design mistake.) But I am happy to be corrected if there is something I miss. Would be great to improve the guidance on this. And yes - deprecate the things that are not recommended anymore.

I meant programmatic guidance. 🙂