3 ms·

I have been a user of make, Ant, Maven and Gradle. And Grunt, Gulp and now npm + webpack in the JavaScript-world. And of all these Maven is by far the better bu

by chvid 9y ago

I have been a user of make, Ant, Maven and Gradle. And Grunt, Gulp and now npm + webpack in the JavaScript-world. And of all these Maven is by far the better build tool. To the creator of these tools: Try to remember that what you are creating is a support tool. A second act to the main development language. It is better if it is not general purpose, it is better if it is not turing complete, it is better if it is less powerful.

andrewmcwatters 9y ago
I don't spend a whole lot of time in the Java world, just enough to take care of small requests. So, I've only experienced maybe half of those. Could you explain a few killer reasons why Maven is the better build tool?
- chii 9y ago
  All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.
  - wst_ 9y ago
    How that's different in Gradle?
    - pjmlp 9y ago
      You are actually programming in Groovy, with all the plus and minus it entails. Regarding the execution speed, IDEs not able to autocomplete, no guarantees about the format that IDEs can easily parse, and it often breaks between releases. Then to compensate for lack of speed, you need to have a running daemon and an in-memory build cache.
    - chii 9y ago
      If your build generated sources (such as via antlr or some other lexer/parser that has a maven plugin) at build time, you know that it's likely to be done at the 'process-sources' phase. If you wrote a custom gradle build script (or indeed, any other custom scripts), then you cannot be sure when that generation of sources is going to happen. Maven forcing you to design your build around maven's fairly strict set of phases (and build lifecycle) means you confirm, and any tooling can compose as long as they also conform.
- chvid 9y ago
  It is a bit like explaining zen but I will try. A programming tool has a certain affordance. It talks to the programmer and says "hey - here is how you use me". Maven says: Hello. I am a just a configuration file. Just put your project's name and the dependencies in here and the defaults will take of the rest. You remember Ant? Please don't turn this into a big mess. Gradle says: Oi buddy. I am a full-fledged scripting language. Anything Maven can do? I can do the same times 10. Plus my syntax is tight - just look at this &#€#"&/+=+++ << '${.&%&}' ... Not even a semi-colon. You see the cool kids over there? They all have advanced build scripts with code generation, variable substitution, dsls, database migration, performance daemons. You need this too (unless you are one of those corporate XML-dorks ... yuck XML, it sucks, no one uses XML anymore). And because we are so cool, we change all the time so you better keep these random files we generate for you under version control: gradle/*, gradlew, gradlew.bat besides your actual build script.

by chvid 9y ago

andrewmcwatters 9y ago

I don't spend a whole lot of time in the Java world, just enough to take care of small requests. So, I've only experienced maybe half of those. Could you explain a few killer reasons why Maven is the better build tool?

chii 9y ago
All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.
- wst_ 9y ago
  How that's different in Gradle?
  - pjmlp 9y ago
    You are actually programming in Groovy, with all the plus and minus it entails. Regarding the execution speed, IDEs not able to autocomplete, no guarantees about the format that IDEs can easily parse, and it often breaks between releases. Then to compensate for lack of speed, you need to have a running daemon and an in-memory build cache.
  - chii 9y ago
    If your build generated sources (such as via antlr or some other lexer/parser that has a maven plugin) at build time, you know that it's likely to be done at the 'process-sources' phase. If you wrote a custom gradle build script (or indeed, any other custom scripts), then you cannot be sure when that generation of sources is going to happen. Maven forcing you to design your build around maven's fairly strict set of phases (and build lifecycle) means you confirm, and any tooling can compose as long as they also conform.
chvid 9y ago
It is a bit like explaining zen but I will try. A programming tool has a certain affordance. It talks to the programmer and says "hey - here is how you use me". Maven says: Hello. I am a just a configuration file. Just put your project's name and the dependencies in here and the defaults will take of the rest. You remember Ant? Please don't turn this into a big mess. Gradle says: Oi buddy. I am a full-fledged scripting language. Anything Maven can do? I can do the same times 10. Plus my syntax is tight - just look at this &#€#"&/+=+++ << '${.&%&}' ... Not even a semi-colon. You see the cool kids over there? They all have advanced build scripts with code generation, variable substitution, dsls, database migration, performance daemons. You need this too (unless you are one of those corporate XML-dorks ... yuck XML, it sucks, no one uses XML anymore). And because we are so cool, we change all the time so you better keep these random files we generate for you under version control: gradle/*, gradlew, gradlew.bat besides your actual build script.