I’ve never experienced Gradle outright breaking itself, but it does deprecate things at a high rate. We try to update dependencies whenever we touch a project, which every few months means making an adjustment for whatever Gradle decided to deprecate and start warning about now.
I’ll still take it every time over Mavens XML based config though.
I would consider myself a very advanced Gradle user. I keep up with experimental/nightly features and best-practices.
I have a love-hate relationship with Gradle. I think it's a better alternative to XML (if you keep it declarative and any kind of stateful logic the hell out of your build scripts).
BUT. Gradle introduces breaking API changes frequently, and they have changed around "best practices" every year or two.
You can easily see this by using "gradle init" to create a new project. It used to be the case that "buildSrc" was the recommended way to do multi-module build logic composition. But it didn't even work with the recommended "libs.versions.toml" file for managing dep versions (you couldn't reference the generated code from within your buildSrc logic).
Sometimes I consider switching to Maven, lol. Have to weigh the effort required to keep up w/ changes against the benefit of using strongly-typed build files.
I honestly don’t understand this position. You’d rather have to update your build or have it be inconsistent or down right broken over having to write some XML?
I’ll still take it every time over Mavens XML based config though.