4 ms·

The article seems to boil to down to: you need to understand Groovy to effectively use Gradle. It's impossible to disagree with this, but this is a realization

The article seems to boil to down to: you need to understand Groovy to effectively use Gradle. It's impossible to disagree with this, but this is a realization you should have after interacting with it after 10 minutes. I may be biased because I'd been using Groovy (Grails apps) for years before I used Gradle so the syntax was not a problem at all for me. For me, the problem with Gradle is the very poor documentation. If I want to do something more complex, I either find the answer in Stackoverflow/the Gradle message board, or I will have to look at the source code of the plugins. Creating a task for scratch is fairly simple, it's interacting with the plugins that's difficult, and while I agree with the author that excessive abstraction through DSLs doesn't help, if these DSLs didn't leak and were properly documented it wouldn't be a problem. Another problem is that it's clear what the right conventions are. Say you want some classes to some exec task. Where should these classes live? Do you use a configuration? Create a sourceSet? Add a directory to an existing sourceSet? You just edit the classpath property in the task to point to a directory? I miss some of the rigidity of Maven, though not its XML syntax. The ability to write actual functions in Groovy (e.g. a closure implementing a file filter) is very much welcome.

emsy 6y ago
Having used Gradle, I disagree. Even if you know Groovy, declarations in Gradle are executed in a certain order and you don't really know what a closure does or what it's side effects are. Sometimes you have to read the source code because the documentation is insufficient. Gradle is not a simple tool and the documentation (last time I was using it) isn't helping.
- cataphract 6y ago
  I agree that order of execution is sometimes problematic in Groovy and you have to use evaluationDependsOn() or afterEvaluate {}. I don't think the DSLs are per se particularly problematic; they generally just set some properties of the task (when they're more complex and yet the abstraction leaks, then they do more harm than do). But yes, the documentation is awful, and is IMO the biggest problem with Gradle.
acaloiar 6y ago
While I agree with you that it should be obvious that Groovy knowledge is necessary to operate Gradle, I think it's important to note that the intersect between people building things in Groovy and people building things in Java/Kotlin is quite small. And for that reason Gradle, with Groovy as its star feature, will always be a fraught choice for a build system. Developers simply have to know too much Groovy to operate Gradle effectively.
- twic 6y ago
  I entirely agree. But i also don't know what the Gradle authors could have done instead. Writing build scripts in Java 1.6 (the latest version at the time Gradle was written) would have been a showstopper. Kotlin didn't exist. XML alone isn't expressive enough, so you would have needed some sort of Ant-like crummy language expressed in XML. Buildr, which i think predated Gradle, used Ruby. I'm not sure Ruby is any better than Groovy here. Perhaps Jython would have been a good choice.
  - zmmmmm 6y ago
    > Perhaps Jython would have been a good choice. It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently. So we seem to be on a never-ending treadmill of wheel reinvention searching for the right compromise between these things.
    - bsder 6y ago
      > It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently. Meson seems to be a counterexample.
      - 6y ago
zmmmmm 6y ago
> this is a realization you should have after interacting with it after 10 minutes The problem is, it is presented as if you don't need to know Groovy. And its not surprising because, if everybody contemplating using Gradle was first told "You should only do this if most of your team is willing to learn Groovy to good proficiency" - hardly anybody would do that. Now groovy is a great language IMHO but I think the way this goes down results in people hating it because they get handed a build as if they should understand it easily and then experience hours and hours of frustration as it exhibits unexpected behavior as they learn all the surprising things about Groovy (and not just Groovy but the Groovy+Gradle DSL dialect that is much weirder than plain Groovy).

emsy 6y ago

Having used Gradle, I disagree. Even if you know Groovy, declarations in Gradle are executed in a certain order and you don't really know what a closure does or what it's side effects are. Sometimes you have to read the source code because the documentation is insufficient. Gradle is not a simple tool and the documentation (last time I was using it) isn't helping.

cataphract 6y ago
I agree that order of execution is sometimes problematic in Groovy and you have to use evaluationDependsOn() or afterEvaluate {}. I don't think the DSLs are per se particularly problematic; they generally just set some properties of the task (when they're more complex and yet the abstraction leaks, then they do more harm than do). But yes, the documentation is awful, and is IMO the biggest problem with Gradle.

acaloiar 6y ago

While I agree with you that it should be obvious that Groovy knowledge is necessary to operate Gradle, I think it's important to note that the intersect between people building things in Groovy and people building things in Java/Kotlin is quite small. And for that reason Gradle, with Groovy as its star feature, will always be a fraught choice for a build system. Developers simply have to know too much Groovy to operate Gradle effectively.

twic 6y ago
I entirely agree. But i also don't know what the Gradle authors could have done instead. Writing build scripts in Java 1.6 (the latest version at the time Gradle was written) would have been a showstopper. Kotlin didn't exist. XML alone isn't expressive enough, so you would have needed some sort of Ant-like crummy language expressed in XML. Buildr, which i think predated Gradle, used Ruby. I'm not sure Ruby is any better than Groovy here. Perhaps Jython would have been a good choice.
- zmmmmm 6y ago
  > Perhaps Jython would have been a good choice. It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently. So we seem to be on a never-ending treadmill of wheel reinvention searching for the right compromise between these things.
  - bsder 6y ago
    > It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently. Meson seems to be a counterexample.
    - 6y ago

zmmmmm 6y ago

> this is a realization you should have after interacting with it after 10 minutes The problem is, it is presented as if you don't need to know Groovy. And its not surprising because, if everybody contemplating using Gradle was first told "You should only do this if most of your team is willing to learn Groovy to good proficiency" - hardly anybody would do that. Now groovy is a great language IMHO but I think the way this goes down results in people hating it because they get handed a build as if they should understand it easily and then experience hours and hours of frustration as it exhibits unexpected behavior as they learn all the surprising things about Groovy (and not just Groovy but the Groovy+Gradle DSL dialect that is much weirder than plain Groovy).