9 ms·

The popularity of Gradle utterly baffles me. It is one of the most infuriating tool I have to deal with, and the one I most regularly flail around with trying t

The popularity of Gradle utterly baffles me. It is one of the most infuriating tool I have to deal with, and the one I most regularly flail around with trying to find out the magic song and dance that’ll make it happy. The existence of two separate programming languages has made the doc situation a nightmare, and I genuinely do not understand why I have to use a real programming language to configure my build.

papaf 6y ago
The popularity of Gradle utterly baffles me. When Gradle got popular the main competition was Maven which involves copy and pasting random pieces of XML from the internet, gave stack traces rather than clear error messages and didn't used to support incremental builds.
- ashtonkem 6y ago
  Before I continue, I would like to point out that Gradle is so bad that it’s making me say “I’d like to go back to XML please”. In any other context this would be an insane thing for me to say, but Gradle is that bad. XML & Maven has the benefit of having a schema. This means that not only do all my pom.xml files look similar, but the IDE can do meaningful autocompletion and semantic checking for me. It’s verbose and ugly, but at least it’s consistent and has good tooling. Gradle on the other hand is a Turing complete system, which just adds another layer of potential errors on top of Java compilation, which is the exact opposite of what I wanted. Now also all of my Gradle files are different and I have no idea why, and what the relative pros and cons of each style is. Could Maven be improved? Sure. I’d kill for something like Cargo for Java. But I did not want to find myself debugging by build tool’s state because I used a setter wrong (true story).
- jordanpg 6y ago
  > copy and pasting random pieces of XML from the internet Also, I don't see that this is a big deal when dealing with a declarative paradigm. In fact, cutting and pasting random bits of declarative code makes a lot of sense to me. You don't need to understand how it's doing what it's doing, only that it will. I have yet to discover a situation where some custom thing I needed couldn't be handled with the Exec Plugin or a custom plugin, which are easy to write. The truth is that these uber-custom things are actually pretty rare if you stick to conventions.
  - ptx 6y ago
    Also, if you use the Kotlin compiler plugin, you can actually write blocks of Kotlin code in your Maven POM if you feel the need.
- naruhodo 6y ago
  OMFG! So much truth in these Gradle threads! I'm glad I'm not the only one.
WatchDog 6y ago
Gradle might not be perfect, but it's so much better than anything else I've used. Simple builds have simple config. Doing more complicated things means you need to learn how the tool works, and that can certainly take some time. I'm really liking the new kotlin DSL, having great IDE support, really makes writing gradle scripts much more pleasant. I do a fair bit of work on node based projects, and the building tooling in the node ecosystem is just so horrible in comparison.
- pas 6y ago
  NodeJS building tool? Do you mean gyp (which is bad) or high level stuff run via npm/yarn (which is meh) like gulp/webpack/ng whose config files are all horrible?
  - lostcolony 6y ago
    I too would like clarity. Every time I end up having to do frontend stuff with gulp/webpack/etc I want to shoot myself, and that's fair. The few times I've had to compile native dealing with gyp has been a crapshoot (sometimes just work, sometimes painful; never as bad as gulp/webpack/etc). But most of the time, for Node development, I just need other node libraries, and it's pretty painless. Not as good as some others, but still -miles- better than Gradle.
- entha_saava 6y ago
  Maybe a bit off topic. But am I the only one who thinks "simple builds should have NO config"?
  - ashtonkem 6y ago
    A strong argument for Cargo. Most cargo manifests are some dependencies and a bit of metadata, which I think we all can agree is reasonable enough.
jacobn 6y ago
Why do I have to learn a second programming language just to configure my build? /s Builds need Turing completeness surprisingly often. Build languages then expand to accommodate, with spaghetti disasters as the result. “But it has to be accessible to new users and can’t be tied to just one language” said SBT as it jumped the shark with its .sbt files. Sigh. Developers get crap tools because developers won’t pay for tooling - if it’s not open source and free we don’t touch it outside of an enterprise environment. And Lo and behold, most tooling is either cobbled together by Enthusiasts, or as user friendly as enterprise ware usually is. (There are, of course, shining exceptions to this, which is great)
- ashtonkem 6y ago
  What’s frustrating is seeing new communities and languages make unforced errors that a review of prior mistakes should easy uncover. The lack of a unified, coherent build tool in Java was a huge mistake. New languages would be well advised to focus on good tooling right out of the gate, rather than putting it off until later.
  - ooobit2 6y ago
    At the very least, limit the scope of the language until a standardized toolset is cross-functional. I'm not not throwing shade at UWP right now.
  - EdwardDiego 6y ago
    Maven has never really been displaced - Gradle only has traction in Android dev, for some reason it became the blessed-by-Google solution. Even when I'm writing Scala I prefer Maven to SBT, I just prefer declarative build tools to DSLs up in my grill.
    - ashtonkem 6y ago
      In my limited experience, Gradle is increasingly popular for Spring Boot applications.
- pas 6y ago
l0b0 6y ago
Not only the tool is infuriating, the language is baffling. With most tools the first time I ever set eyes on the configuration I had a pretty good idea what was going on without reading any documentation. With Gradle it's like someone invented proto-Java and just left it at that. A build file which was actual Java would be much easier to understand and most importantly edit, because then I could get the IDE to help explore the API. As a side note, this is probably (intentionally or not) the same tactic that Microsoft used in the 00s to avoid competition: keep changing things fast so that anybody using your tool chain a) has to follow your lead to keep up, b) ends up with huge sunk cost, and c) (if they trust whoever's behind Gradle) keeps being reminded how much they innovate.
- mrec 6y ago
  So much this. I've tried multiple times to grok it and it just slid straight back out of my brain leaving me with the same puddle of syntax soup I started with. I've never encountered anything else even close to this bad. Not to mention that build config is probably the absolute last place you want a weird unreadable language nobody knows, because it tends to be touched so rarely that nobody builds up any familiarity with it.
- aphexairlines 6y ago
  You can write nearly all of your gradle build logic in java if you want. Place the java files to configure your gradle build in buildSrc/src/main/java, then write a single line of kotlin in your build.gradle.kts to call your java code. Here's the javadoc: https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html https://docs.gradle.org/current/javadoc/org/gradle/api/Proje...
  - deleted 6y ago
    [deleted]
aphexairlines 6y ago
> flail around with trying to find out the magic song and dance that’ll make it happy If you switch to the Kotlin flavor of Gradle then this goes away. You just have to make the compiler happy then, same as for application code.
dreamcompiler 6y ago
Whatever happened to Ant? I know Ant sucked because of XML, but at least XML has a lot of tooling around it. Why do people use Gradle instead of Ant?
tdeck 6y ago
It's worth considering Bazel instead which is much cleaner and easier to understand. Unfortunately its official support and platform adoption are limited

papaf 6y ago

The popularity of Gradle utterly baffles me. When Gradle got popular the main competition was Maven which involves copy and pasting random pieces of XML from the internet, gave stack traces rather than clear error messages and didn't used to support incremental builds.

ashtonkem 6y ago
Before I continue, I would like to point out that Gradle is so bad that it’s making me say “I’d like to go back to XML please”. In any other context this would be an insane thing for me to say, but Gradle is that bad. XML & Maven has the benefit of having a schema. This means that not only do all my pom.xml files look similar, but the IDE can do meaningful autocompletion and semantic checking for me. It’s verbose and ugly, but at least it’s consistent and has good tooling. Gradle on the other hand is a Turing complete system, which just adds another layer of potential errors on top of Java compilation, which is the exact opposite of what I wanted. Now also all of my Gradle files are different and I have no idea why, and what the relative pros and cons of each style is. Could Maven be improved? Sure. I’d kill for something like Cargo for Java. But I did not want to find myself debugging by build tool’s state because I used a setter wrong (true story).
jordanpg 6y ago
> copy and pasting random pieces of XML from the internet Also, I don't see that this is a big deal when dealing with a declarative paradigm. In fact, cutting and pasting random bits of declarative code makes a lot of sense to me. You don't need to understand how it's doing what it's doing, only that it will. I have yet to discover a situation where some custom thing I needed couldn't be handled with the Exec Plugin or a custom plugin, which are easy to write. The truth is that these uber-custom things are actually pretty rare if you stick to conventions.
- ptx 6y ago
  Also, if you use the Kotlin compiler plugin, you can actually write blocks of Kotlin code in your Maven POM if you feel the need.
naruhodo 6y ago
OMFG! So much truth in these Gradle threads! I'm glad I'm not the only one.

WatchDog 6y ago

Gradle might not be perfect, but it's so much better than anything else I've used. Simple builds have simple config. Doing more complicated things means you need to learn how the tool works, and that can certainly take some time. I'm really liking the new kotlin DSL, having great IDE support, really makes writing gradle scripts much more pleasant. I do a fair bit of work on node based projects, and the building tooling in the node ecosystem is just so horrible in comparison.

pas 6y ago
NodeJS building tool? Do you mean gyp (which is bad) or high level stuff run via npm/yarn (which is meh) like gulp/webpack/ng whose config files are all horrible?
- lostcolony 6y ago
  I too would like clarity. Every time I end up having to do frontend stuff with gulp/webpack/etc I want to shoot myself, and that's fair. The few times I've had to compile native dealing with gyp has been a crapshoot (sometimes just work, sometimes painful; never as bad as gulp/webpack/etc). But most of the time, for Node development, I just need other node libraries, and it's pretty painless. Not as good as some others, but still -miles- better than Gradle.
entha_saava 6y ago
Maybe a bit off topic. But am I the only one who thinks "simple builds should have NO config"?
- ashtonkem 6y ago
  A strong argument for Cargo. Most cargo manifests are some dependencies and a bit of metadata, which I think we all can agree is reasonable enough.

jacobn 6y ago

Why do I have to learn a second programming language just to configure my build? /s Builds need Turing completeness surprisingly often. Build languages then expand to accommodate, with spaghetti disasters as the result. “But it has to be accessible to new users and can’t be tied to just one language” said SBT as it jumped the shark with its .sbt files. Sigh. Developers get crap tools because developers won’t pay for tooling - if it’s not open source and free we don’t touch it outside of an enterprise environment. And Lo and behold, most tooling is either cobbled together by Enthusiasts, or as user friendly as enterprise ware usually is. (There are, of course, shining exceptions to this, which is great)

ashtonkem 6y ago
What’s frustrating is seeing new communities and languages make unforced errors that a review of prior mistakes should easy uncover. The lack of a unified, coherent build tool in Java was a huge mistake. New languages would be well advised to focus on good tooling right out of the gate, rather than putting it off until later.
- ooobit2 6y ago
  At the very least, limit the scope of the language until a standardized toolset is cross-functional. I'm not not throwing shade at UWP right now.
- EdwardDiego 6y ago
  Maven has never really been displaced - Gradle only has traction in Android dev, for some reason it became the blessed-by-Google solution. Even when I'm writing Scala I prefer Maven to SBT, I just prefer declarative build tools to DSLs up in my grill.
  - ashtonkem 6y ago
    In my limited experience, Gradle is increasingly popular for Spring Boot applications.
pas 6y ago

l0b0 6y ago

Not only the tool is infuriating, the language is baffling. With most tools the first time I ever set eyes on the configuration I had a pretty good idea what was going on without reading any documentation. With Gradle it's like someone invented proto-Java and just left it at that. A build file which was actual Java would be much easier to understand and most importantly edit, because then I could get the IDE to help explore the API. As a side note, this is probably (intentionally or not) the same tactic that Microsoft used in the 00s to avoid competition: keep changing things fast so that anybody using your tool chain a) has to follow your lead to keep up, b) ends up with huge sunk cost, and c) (if they trust whoever's behind Gradle) keeps being reminded how much they innovate.

mrec 6y ago
So much this. I've tried multiple times to grok it and it just slid straight back out of my brain leaving me with the same puddle of syntax soup I started with. I've never encountered anything else even close to this bad. Not to mention that build config is probably the absolute last place you want a weird unreadable language nobody knows, because it tends to be touched so rarely that nobody builds up any familiarity with it.
aphexairlines 6y ago
You can write nearly all of your gradle build logic in java if you want. Place the java files to configure your gradle build in buildSrc/src/main/java, then write a single line of kotlin in your build.gradle.kts to call your java code. Here's the javadoc: https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html https://docs.gradle.org/current/javadoc/org/gradle/api/Proje...
- deleted 6y ago
  [deleted]

aphexairlines 6y ago

> flail around with trying to find out the magic song and dance that’ll make it happy If you switch to the Kotlin flavor of Gradle then this goes away. You just have to make the compiler happy then, same as for application code.

dreamcompiler 6y ago

Whatever happened to Ant? I know Ant sucked because of XML, but at least XML has a lot of tooling around it. Why do people use Gradle instead of Ant?

tdeck 6y ago

It's worth considering Bazel instead which is much cleaner and easier to understand. Unfortunately its official support and platform adoption are limited