Almost 40 years of software engineering experience - and I hate Gradle more than I would consider reasonable. In fact, I consider Gradle the absolute worst software system out there.
Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one directive - and your build breaks in most weird and incomprehensible ways.
And then there is the whole notion of stability (I mean "contract stability.") Almost every single release of Gradle breaks things in some subtle ways. I can take a project from the olden UNIX days with its Makefile and that Makefile will work in gmake in the freshest Linux distro, using gmake release that was produced multiple decades after Stu Feldman's make. It doesn't require a very specific version of libc or kernel. Because it is 1. Written portably and 2. It treats its behavior (jokes about using the Tab character aside) as a contract and it doesn't violate it just because some poorly educated software engineer decided that it would be a good idea to change the behavior in the upcoming release.
Almost 40 years of software development and I think you're overlooking the strength of Gradle. Before Gradle if you wanted any kind of build step that was slightly outside of the norm you had to roll your own maven plugin or god forbid try to script something with ant in xml. Using a DSL in a scripting language was a smart move.
What I hated most about Gradle is that groovy is untyped. You'd make a change and wait for your build to complete only to find out minutes later that you made a typo or some other innocuous mistake. Glad they introduced Kotlin DSL.
I didn't notice the breaking changes much when we heavily used gradle. Gradle also comes with gradlew, which bootstraps your gradle project with the exact gradle version that is needed to build that project, so you can take an old gradle project and build it regardless of all those breaking changes that you mention.
Friction made people think if they really need this custom step, now every single gradle project has a lot of poorly thought out custom stuff, often something which doesn't belong there.
Offense is the best defense? Gradle is usually lagging behind, being unable to build projects with the latest JDK a week after it was released because of some asm bytecode dependency bullshit.
I have an unreasonable hatred of gradle and its imperative, choose-your-own-language build files, every buildfile being structured differently.
Hateful.
Not even talking about how slow it is, no I don't want the garbage demon running somewhere.
There is only one reason to use Gradle, the poor souls that have to put up with Android development requirements, and have fun with updating their projects, every single time there are DSL changes.
I'm by-and-large fine with XML, having used it for many a year; however I really like working with XML when I can use Guile's SXML layer. For Maven it's not that important because POMs are simple enough, but for more complex things it's nice having a useful tool.
I actually don't mind Ant very much, but I haven't had good luck using Ivy for dependency management. Maven's been very nice in the decade and a half I've used it, Gradle's always felt off to me. I think there was also another Java build tool written in like Ruby or something, but I'm blanking on the name at the moment.
Before Maven came to be, we had built nice macros on our Ant builds that were quite similar to how Maven works, but Ivy wasn't also around.
Eventually Maven grew on me, however I would rather go back to Ant than deal with Gradle, the time using it when I did Android development a few years ago, was more than enough.
Yeah I have long felt that if we think we need gradle, we should consider doing less crazy stuff in our build. Maven is plenty and any time I get back to a repo that has that instead of gradle or sbt I’m much happier.
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.
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.
Almost 40 years of software engineering experience - and I hate Gradle more than I would consider reasonable. In fact, I consider Gradle the absolute worst software system out there.
Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one directive - and your build breaks in most weird and incomprehensible ways.
And then there is the whole notion of stability (I mean "contract stability.") Almost every single release of Gradle breaks things in some subtle ways. I can take a project from the olden UNIX days with its Makefile and that Makefile will work in gmake in the freshest Linux distro, using gmake release that was produced multiple decades after Stu Feldman's make. It doesn't require a very specific version of libc or kernel. Because it is 1. Written portably and 2. It treats its behavior (jokes about using the Tab character aside) as a contract and it doesn't violate it just because some poorly educated software engineer decided that it would be a good idea to change the behavior in the upcoming release.
Almost 40 years of software development and I think you're overlooking the strength of Gradle. Before Gradle if you wanted any kind of build step that was slightly outside of the norm you had to roll your own maven plugin or god forbid try to script something with ant in xml. Using a DSL in a scripting language was a smart move.
What I hated most about Gradle is that groovy is untyped. You'd make a change and wait for your build to complete only to find out minutes later that you made a typo or some other innocuous mistake. Glad they introduced Kotlin DSL.
I didn't notice the breaking changes much when we heavily used gradle. Gradle also comes with gradlew, which bootstraps your gradle project with the exact gradle version that is needed to build that project, so you can take an old gradle project and build it regardless of all those breaking changes that you mention.
Friction made people think if they really need this custom step, now every single gradle project has a lot of poorly thought out custom stuff, often something which doesn't belong there.
Exactly.
Just like being weightless is fun - until you need to go to the toilet.
Friction or gravity in systems like this is a feature not a problem.
Every single time I experience Gradle, I’m grateful Maven exists.
I mentally demote anything that says "maxxing" to the stupid pile
Rightfully so.
Offense is the best defense? Gradle is usually lagging behind, being unable to build projects with the latest JDK a week after it was released because of some asm bytecode dependency bullshit.
I have an unreasonable hatred of gradle and its imperative, choose-your-own-language build files, every buildfile being structured differently.
Hateful.
Not even talking about how slow it is, no I don't want the garbage demon running somewhere.
There is only one reason to use Gradle, the poor souls that have to put up with Android development requirements, and have fun with updating their projects, every single time there are DSL changes.
As someone who uses gradle largely out of inertia, I'm curious what you would pick as a better alternative.
Maven as always.
I don't suffer from XML allergy, and Gradle is Ant all over again.
Worse, because it relies on a slow scripting language, or having to go through Kotlin, plus a background deamon.
I'm by-and-large fine with XML, having used it for many a year; however I really like working with XML when I can use Guile's SXML layer. For Maven it's not that important because POMs are simple enough, but for more complex things it's nice having a useful tool.
I actually don't mind Ant very much, but I haven't had good luck using Ivy for dependency management. Maven's been very nice in the decade and a half I've used it, Gradle's always felt off to me. I think there was also another Java build tool written in like Ruby or something, but I'm blanking on the name at the moment.
Before Maven came to be, we had built nice macros on our Ant builds that were quite similar to how Maven works, but Ivy wasn't also around.
Eventually Maven grew on me, however I would rather go back to Ant than deal with Gradle, the time using it when I did Android development a few years ago, was more than enough.
Yeah I have long felt that if we think we need gradle, we should consider doing less crazy stuff in our build. Maven is plenty and any time I get back to a repo that has that instead of gradle or sbt I’m much happier.
Sbt is by far the worst. It’s the bane of my existence.
I always hated Maven, until I started using Gradle.
And for those that are allergic Maven 4 will offer alternative file types via extensions!
Is it too late to stop that happening? Nobody wants maven + yaml or whatever else they will add. XML is the correct format.
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.
> 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.
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.
No. Builds are not simple