Rendered at 02:40:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Postosuchus 2 days ago [-]
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.
lobofta 2 days ago [-]
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.
isbvhodnvemrwvn 2 days ago [-]
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.
DrScientist 2 days ago [-]
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.
microflash 2 days ago [-]
Every single time I experience Gradle, I’m grateful Maven exists.
TheServitor 2 days ago [-]
I mentally demote anything that says "maxxing" to the stupid pile
poolnoodle 2 days ago [-]
Rightfully so.
ysleepy 2 days ago [-]
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.
pjmlp 2 days ago [-]
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.
RandomBK 2 days ago [-]
As someone who uses gradle largely out of inertia, I'm curious what you would pick as a better alternative.
pjmlp 2 days ago [-]
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.
tmtvl 2 days ago [-]
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.
pjmlp 2 days ago [-]
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.
blandflakes 2 days ago [-]
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.
vips7L 2 days ago [-]
Sbt is by far the worst. It’s the bane of my existence.
johnyzee 2 days ago [-]
I always hated Maven, until I started using Gradle.
vips7L 2 days ago [-]
And for those that are allergic Maven 4 will offer alternative file types via extensions!
panny 2 days ago [-]
Is it too late to stop that happening? Nobody wants maven + yaml or whatever else they will add. XML is the correct format.
plmpsu 2 days ago [-]
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 2 days ago [-]
> 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 2 days ago [-]
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.