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.
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.
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.
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.
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.
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.
> 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.
Scons is another example of Python as the config language. In fact most of the times you don't need a comlicated DSL, or any language at all. Look at Webpack, npm, Android Blueprint or Bazel which more or less is just JSON-flavor, or Rusts Cargo.toml which is just toml markup.
You can get very very far with just a list of files and some config properties, if there is something complicated needed in the configuration the markup can refer to an external script.
In fact not accidentally mixing the configuration step with the execution step, as Gradle often does, can be considered a feature.
Cargo isn't just TOML, it's TOML, plus a build.rs script, written in Rust, for everything you can't express in the TOML.
I agree that a lot of the time, you don't need Gradle's sophistication. But large, complex projects, in my experience, inevitably develop strange and unusual build needs. At that point, if your tool doesn't support them naturally, the complexity ends up going somewhere else - you have to write plugins, or standalone tools, or build script generators, or manage a lot of repetition in the build script, or multiply subprojects, etc, so you can do what you need to do.
> Cargo isn't just TOML, it's TOML, plus a build.rs script, written in Rust, for everything you can't express in the TOML.
Cargo is nice--until you have to coexist with something else that also wants to own the world of the build process.
And that build.rs script causes a LOT of heartburn when your needs get larger or you need repeatable builds.
I don't know what the right answer is, but cargo is exactly the kind of system you describe that you have to start working around when you have more sophisticated needs.
> 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).
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.