Gradle
From APIDesign
These days it is common to praise Apache's Gradle and dishonest Maven. It is hard to find articles like Maven's Inflexibility Is Its Best Feature that would try to put some balance into the build tool flamewar raging around.
It is true that Maven is far from perfect, and possibly Gradle learned from Maven mistakes in many areas, but there is one thing where Gradle regressed totally - and which I consider far bigger problem than any shortcomings of Maven: Gradle brought halting problem into your build job!
Contents |
Why Should I Care about halting problem?
If you don't know what a halting problem is, you may belong into the camp of people who believe one can write program to solve any (digitalizable) problem. Well, you cannot - there are (digitalized) problems that computer's cannot solve - halting problem is core one. Its implications are huge. As a result of halting problem existence it is impossible to write a program that would completely understand behavior of all other programs.
That of course won't stop people from trying to write such program (as illustrated in the essay about finite automaton), but the only way to really analyse what a program does is to restrict language in which it is written!
Declarative vs. Imperative
Restricted language is in my opinion the biggest difference between imperative and declarative specification of actions (and by declarative I don't mean functional as such languages suffer from halting problem presence as well). One should not be able to express everything that is possible in imperatively in declarative language.
Btw. the important element that needs to be avoided is while construct - e.g. repeating some code block indefinitely - repeating something via for cycle - e.g. given number of times is OK. Languages that have just fors fall into the wikipedia:Primitive_recursive_function definition and are not subject to halting problem - all of them halt.
As such, if you want a computer program to understand some language, it is important to make the language declarative - e.g. to make it at most as complex as wikipedia:Primitive_recursive_function.
Ant, Maven, Gradle and Tooling
Ant is in general considered too lowlevel, too imperative. It didn't have direct way to express while, but as it has a way to invoke a target recursively, it was imperative enough. As a result it was impossible for a tool like NetBeans to analyse a generic Ant script and extract for example project's classpath and/or test classpath. In spite of that NetBeans IDE 4.0 used Ant as its default build harness and supported two way editing - one could change scripts and configutation files from a command line and the IDE was able to pick the changes up and adjust its settings automatically. However, this worked only for small subset of Ant projects with well defined structure the NetBeans IDE could understand to.
Some (especially Ant fans) consider Maven too magical. Doing too many things in a blackbox. Well, that is what one gets when doing things in declarative way - you don't specify commands to compile, copy, delete like in Ant - you express intentions. What actions your intentions result too is a blackmagic. Maven's language to express intention is a DSL embedded into XML. Yeah, the XML hype is over - but clearly there is no way to express while statement and as such the Maven configuration is not subject to halting problem and it can be analyzed by the tools. When NetBeans IDE decided to support Maven out of the box, we could only tech it to understand the pom file dependency section and few configuration options of most commonly used plugins (like maven-compiler-plugin - to read the source and target levels, encoding, etc.). Understanding completely unknown Maven projects becomes easy - just open then in the IDE and all the settings are immediately known. Change the pom file on disk, and the changes are immediately reflected. Don't believe it? Get latest version of NetBeans and give it a try - Maven support in NetBeans is really smooth.
Now you can probably see what is the biggest Gradle flaw. Yes, by choosing Groovy (which is fragile with respect to halting problem) as its configuration language the system immediately lost all its tooling potential. We are back in the Ant-age! You need to run the build to understand what it will actually do. From a tooling story perspective: Gradle is total disaster.
Follow
