I think thats the major issue I have with Gradle in large orgs: it doesn't lend itself to reuse, but I don't blame it either: it's not really meant to do that.
I'm dating myself, but 20 years ago, we had Ant. It was very much a blunt hammer like CMake. Maven came along and was like "how about we choose a definitive way to organize projects, make that repeatable". You lose flexibility but gain speed/reuse.
I see Gradle more of a replacement for Ant than Maven in this regard. Infinite flexibility, at the cost of speed/reuse.
>it doesn't lend itself to reuse, but I don't blame it either: it's not really meant to do that.
Only if you keep writing more logic into build.gradle.kts.
Writing custom Gradle plugins has been the standard and recommended way to configure your projects for years now. Aside from a few footguns (lol extensions not being resolved at configuration time and needing providers everywhere), it allows you to mostly skip configuration steps.
I'm dating myself, but 20 years ago, we had Ant. It was very much a blunt hammer like CMake. Maven came along and was like "how about we choose a definitive way to organize projects, make that repeatable". You lose flexibility but gain speed/reuse.
I see Gradle more of a replacement for Ant than Maven in this regard. Infinite flexibility, at the cost of speed/reuse.