4 ms·

Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.

by Nutomic 11y ago

merb 11y ago
Actually criticism is mostly personal however there are a few: - I dislike the DSL // not a really useful criticism I know. - Some things needs Groovy which isn't a mainstream language - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support. - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intellij - Bigger build files could be really slow (mostly resolved in newer versions) Btw. whats really really good on Gradle is the dependency resolution, which is really fast compared to something like sbt.
- vorg 11y ago
  > Groovy which isn't a mainstream language Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!
  - pjmlp 11y ago
    Right now, with the Grails hype gone from German's JUG meetings, I would say Gradle is the only thing keeping Groovy alive.
lmm 11y ago
There's no clear separation between build config and random Groovy expressions. There's not even a spec for what a .gradle file looks like. That's fine for "get this done quickly", but ultimately it encourages people to put one-off hacks in the build file that become a maintainability nightmare. (And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Maven's)
- pswenson 11y ago
  So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.
  - lmm 11y ago
    You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.
    - zmmmmm 11y ago
      I've arrived at the opposite opinion over time ... I think people need to recognise that a build system is code. When we pretend it isn't we ultimately end up contorting the system to make up for the missing flexibility. A lot of it looks declarative, but it is not always the case. Sometimes you want imperative constructs. The build should be recognized as code, maintained as code and use a first class language suited to the job. I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.
meddlepal 11y ago
The documentation for Gradle is very thorough but man is it a PITA to find answers for stuff, like, for example, how do I GZIP compress the output the application plugins distTar task. The answer is not something you would just arrive at when you do figure it out and it's also not documented anywhere. Gradle's biggest problem is that it's too flexible.
pjmlp 11y ago
- Takes up GB of memory compared with any other JVM build tool - It is the slowest of all JVM build tools available. - Hard to know what DSL should look like in each version. - Seems like the only thing keeping Groovy afloat

Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.

by Nutomic 11y ago

Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.

merb 11y ago

Actually criticism is mostly personal however there are a few: - I dislike the DSL // not a really useful criticism I know. - Some things needs Groovy which isn't a mainstream language - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support. - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intellij - Bigger build files could be really slow (mostly resolved in newer versions) Btw. whats really really good on Gradle is the dependency resolution, which is really fast compared to something like sbt.

vorg 11y ago
> Groovy which isn't a mainstream language Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!
- pjmlp 11y ago
  Right now, with the Grails hype gone from German's JUG meetings, I would say Gradle is the only thing keeping Groovy alive.

lmm 11y ago

There's no clear separation between build config and random Groovy expressions. There's not even a spec for what a .gradle file looks like. That's fine for "get this done quickly", but ultimately it encourages people to put one-off hacks in the build file that become a maintainability nightmare. (And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Maven's)

pswenson 11y ago
So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.
- lmm 11y ago
  You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.
  - zmmmmm 11y ago
    I've arrived at the opposite opinion over time ... I think people need to recognise that a build system is code. When we pretend it isn't we ultimately end up contorting the system to make up for the missing flexibility. A lot of it looks declarative, but it is not always the case. Sometimes you want imperative constructs. The build should be recognized as code, maintained as code and use a first class language suited to the job. I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.

meddlepal 11y ago

The documentation for Gradle is very thorough but man is it a PITA to find answers for stuff, like, for example, how do I GZIP compress the output the application plugins distTar task. The answer is not something you would just arrive at when you do figure it out and it's also not documented anywhere. Gradle's biggest problem is that it's too flexible.

pjmlp 11y ago

- Takes up GB of memory compared with any other JVM build tool - It is the slowest of all JVM build tools available. - Hard to know what DSL should look like in each version. - Seems like the only thing keeping Groovy afloat