I've just wanted to share with you a small article that we've prepared at Allegro: https://blog.allegro.tech/2024/11/popular-gradle-mistakes-and-how-to-avoid-them.html It's data based on our repositories (an ecommerce corporation), so maybe it can help see where are "random" clients struggling 😉

task.withType<...> { ... }

unfortunately causes those tasks to be eagerly configured. you want to use

task.withType<...>().configureEach { ... }

to maintain defer task configuration until it is necessary. https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#sec:how_do_i_defer_configuration

yes! we mentioned it at the end, and we will emphasise in part2! 😄 (we plan to add some insights about:

configuration avoidance

,

convention plugins.

,

platform dependencies

and some most used plugins)

Because it wastes time of everyone and everything running that build. Who could need more explanation. :-) Changing the default is virtually impossible without breaking backwards compatibility rules. Or at least it would be very strange. You would die example need to deprecate the call in Gradle 9 and then change its default to lazy and undeprecate in 10.0. But then if someone upgrades from 8 to 10, it just potentially breaks. And if one follows my suggested upgrade path to go from latest major patch to next major's patch and on the way fixing all deprecation warnings, he will change all invocations to

configureEach

for the 9-step, just for being able to remove them in the 10-step again if he even notices.

yeah, I get it! Maybe gradle should have some kind of automigrator? you know, when gradle wrapper task updates gradle version in my project it could run some kind of migration (like openrewrite binary :)) It's painful to always be backward compatible (kudos for that!)

Feel free to suggest it to the Gradle guys, but I tend to doubt that it will come. Especially the

wrapper

task is only for writing the wrapper files, not migrating anything. And I don't think it will really work nicely, besides that I doubt they have the resources to do something like that.

maybe it's time to have

./gradlew modernize

😉

The problem is prioritising this work against everything else each team has to do. We work for other companies, not gradle. We all want to do what's best as early as possible and we never have the time or the amount of people needed to do it. KYC and go with empathy

The fact that it's still not a configuration time warning is where the problem lays Yes, migration could be painful, but it's way better to know that problem exists without need for debugging it with But I'm very sceptical about auto-migration tools for this

Not really, because there are valid situations where you do want / need to use it. Warning about any use of it would effectively be deprecating it and that is unfortunately not appropriate.

what is a valid situation? For valid ones better to introduce explicit, eager resolution API, not rely on very subtle difference

Yeah, well, one could indeed use

.all

and deprecate that method.

For catching

.withType

without configure each,

.all

calls, and a dozen others, my team ships a set of Lint checks you can apply to your Gradle plugin project https://developer.android.com/jetpack/androidx/releases/lint It's called android lint but it runs on JVM projects just fine