4 ms·

I don't understand why this is still a matter of discussion after so many years of blood and tears. Maven is dead, everyone else is moving to Gradle (Spring, An

by koevet 13y ago

I don't understand why this is still a matter of discussion after so many years of blood and tears. Maven is dead, everyone else is moving to Gradle (Spring, Android, Hibernate, etc.). I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS. If you work in Java and you are still stuck with Maven, please, take a look at Gradle.

auvrw 13y ago
> If you work in Java and you are still stuck with Maven, please, take a look at Gradle. or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks). after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically, "do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.
- ajanuary 13y ago
  Ironically the biggest pain with Ivy is that 99% of your dependencies will be pulled in from Maven oriented sources, so you still have to deal with Maven's deficiencies around dependency configurations.
  - smrtinsert 13y ago
    how so? you can even use regexs easily to specify which transitive deps you don't want. what are you missing?
- koevet 13y ago
  Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine. Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle. Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
  - gaius 13y ago
    I looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
    - koevet 13y ago
      Well, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be. A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
    - IanCal 13y ago
      > Then carried on using Makefiles How do you deal with versioned dependencies with Makefiles?
      - gaius 13y ago
        Obviously the Makefiles gets branched with the err, branch. And merged with the merge.
        IanCal 13y ago
        I don't mean how do you version a Makefile, but if your project depends on 6 libraries (with various version requirements) each with their own sets of dependencies, how do you use Makefiles to download & install all of them?
- clumsysmurf 13y ago
  Actually, according to the May 2013 Thoughtworks Tech Radar at http://www.thoughtworks.com/radar http://www.thoughtworks.com/radar In the Tools category, Gradle is "Adobt", while Maven is on "Hold". You can read the full report but I'll exert the relevant section: "Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex." They had a more elaborate explanation in previous editions.
  - pjmlp 13y ago
    In many enterprises we work for, Maven is still in the "to adopt" phase. Having said this, I am also an Ant guy for simple projects. Too many scars from an Ant -> Maven migration. All pom.xml files ended up more complex than the original build.xml files, as Maven did not have proper support for the way the build was working before.
  - beamso 13y ago
    And the last in the list of references in the last page of the PDF is : Why Everyone (Eventually) Hates (or Leaves) Maven : http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html http://nealford.com/memeagora/2013/01/22/why_everyone_eventu...
Randgalt 13y ago
No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven. I hated Maven until I tried the alternatives.
- koevet 13y ago
  > incomprehensible build files ala Ant Please, explain incomprehensible (or show an example)
  - davidgerard 13y ago
    Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity! To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.
  - Randgalt 13y ago
    Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.
    - koevet 13y ago
      Thanks for the link. To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.
      - 13y ago

by koevet 13y ago

auvrw 13y ago

> If you work in Java and you are still stuck with Maven, please, take a look at Gradle. or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks). after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically, "do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.

ajanuary 13y ago
Ironically the biggest pain with Ivy is that 99% of your dependencies will be pulled in from Maven oriented sources, so you still have to deal with Maven's deficiencies around dependency configurations.
- smrtinsert 13y ago
  how so? you can even use regexs easily to specify which transitive deps you don't want. what are you missing?
koevet 13y ago
Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine. Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle. Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
- gaius 13y ago
  I looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
  - koevet 13y ago
    Well, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be. A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
  - IanCal 13y ago
    > Then carried on using Makefiles How do you deal with versioned dependencies with Makefiles?
    - gaius 13y ago
      Obviously the Makefiles gets branched with the err, branch. And merged with the merge.
      - IanCal 13y ago
        I don't mean how do you version a Makefile, but if your project depends on 6 libraries (with various version requirements) each with their own sets of dependencies, how do you use Makefiles to download & install all of them?
clumsysmurf 13y ago
Actually, according to the May 2013 Thoughtworks Tech Radar at http://www.thoughtworks.com/radar http://www.thoughtworks.com/radar In the Tools category, Gradle is "Adobt", while Maven is on "Hold". You can read the full report but I'll exert the relevant section: "Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex." They had a more elaborate explanation in previous editions.
- pjmlp 13y ago
  In many enterprises we work for, Maven is still in the "to adopt" phase. Having said this, I am also an Ant guy for simple projects. Too many scars from an Ant -> Maven migration. All pom.xml files ended up more complex than the original build.xml files, as Maven did not have proper support for the way the build was working before.
- beamso 13y ago
  And the last in the list of references in the last page of the PDF is : Why Everyone (Eventually) Hates (or Leaves) Maven : http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html http://nealford.com/memeagora/2013/01/22/why_everyone_eventu...

Randgalt 13y ago

No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven. I hated Maven until I tried the alternatives.

koevet 13y ago
> incomprehensible build files ala Ant Please, explain incomprehensible (or show an example)
- davidgerard 13y ago
  Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity! To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.
- Randgalt 13y ago
  Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.
  - koevet 13y ago
    Thanks for the link. To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.
    - 13y ago