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.
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.
Here's the javadoc: https://docs.gradle.org/current/javadoc/org/gradle/api/Proje...
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.
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).
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.
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)
Even when I'm writing Scala I prefer Maven to SBT, I just prefer declarative build tools to DSLs up in my grill.
And sbt is just bad all around on top of all this, and it should feel bad.
To be fair, this is due also to the fact that opensource tools are mostly guaranteed to outlive their developers. Should Microsoft go bankrupt tomorrow (don't laugh, it basically happened to SUN), most of their traditional tooling would disappear. In contrast, Gcc might be old and crusty, but it will go on forever like a cockroach.
I'm not sure i understand this argument
crap Linux because developers won’t pay for Linux
crap git because developers won’t pay for git
...that's clearly not the case, no? Every day we use a bunch of developer tools that are not just crap, but amazing and great to work with, and were built as open source. So I'm not sure about equating open source with crap experience.
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.
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.