[plmpsu]

Gradle is really powerful if you know what you're doing and you take the time and effort to keep your build optimized, sane, and working. I recently built a Gradle plug-in that allows us to build native components on a remote system (z/OS) and integrate these tasks and artifacts with the native Gradle model so that Gradle takes care of caching and parallel task execution. I'm sure this is possible with other build tools as well, though, but the Gradle model fit our use case nicely.

I think any complicated build system will eventually devolve regardless of the build tool if it's not properly maintained; the variability of the required tasks is just too high.

Gradle does seem to be moving fast with regards to Java support in general changes and improvements in the build tool. It takes effort to keep up, but it's worthwhile.

[DrScientist]

> you take the time and effort to keep your build optimized, sane, and working

But isn't the key job of a build system to 'just work'.

Ie it's executable documentation of how to build/test the software.

ie really shouldn't need constant maintenance, especially if the code hasn't changed.

[plmpsu]

For simple use cases, sure. But when you start to have to build artifacts with different dependency versions, JDK versions, architectures, etc., then this complexity has to be somewhere, and Gradle can do that for you if you know how to wield it.

We are a large enterprise shop with many projects being built on different machines, architectures, technologies, etc. We took the time to become decent in Gradle, and it works great for us.

[sharts]

No. Builds are not simple