7 ms·

My shop relies on an Ant script for our builds. We still manage our dependencies by hand and package everything ourselves, but we've got a system that works. W

My shop relies on an Ant script for our builds. We still manage our dependencies by hand and package everything ourselves, but we've got a system that works. We're (slowly) working on doing an upgrade to all our infrastructure, so one of the things we've examined is moving from Ant to Maven. While there's a lot of people that've expressed dissatisfaction with it, you can't ignore the fact that tutorials, setup instructions and such seemingly to a one are written with a pom.xml in mind. So to that end, I wonder what place Gradle has. I've played with it a bit outside of this project and it seems nice enough and does its job, I guess I just don't understand what niche it fills that neither Ant nor Maven don't already handle?

reitanqild 10y ago
It seems to me that gradle has a performance edge (things like incremental rebuilds etc) although I haven't used it so I cannot say for sure. My inner grumpy anti-hipster says it is mostly about riding the tail of the anti-xml wave though: "no xml? Then it must be good!"
- pjmlp 10y ago
  From my Android SDK experience, Ant and Maven are much faster than Gradle. If you check the developer Q&A videos at Google IO 2016, one of the issues that got discussed was precisely the slow builds. It is also interesting that they had to re-write the public API in Java for Gradle 3, as part of their speed improvements.
  - darylteo 10y ago
    From what I know, the Groovy runtime was a constant-time bottle neck for all builds (time to initialise, interpret etc.), hence the perceived "slow builds" for any small to medium sized project.
  - Eridrus 10y ago
    My experience is similar to yours - when not using the dragle daemon. IIRC the gradle daemon made things competetive if not faster, though it's been a while since I tried.
    - pjmlp 10y ago
      Yet Ant and Maven don't need a daemon to be fast. There is a recent post from the Android team, where they advise to allocate between 2 and 5 GBs for the daemon!
      - Eridrus 10y ago
        Wow, that's totally crazy. Is that due to Android projects needing to link against Android which is a very large library? I don't recall it being that dire for my non-Android project, but I don't recall checking my mem usage either...
        pjmlp 10y ago
        Due to the DEX conversion.
manyxcxi 10y ago
One thing you will find in more complicated builds is that, short of writing your own Maven plugins, you will still need Ant scripts or at least some very arcane incantations of Maven to get the job done. I've used Maven for a long time and the vast majority of my projects are Maven based- for the ones that follow the archetype, Maven is a pretty easy fit. As a matter of fact if you've got an IDE like IntelliJ, it'll build your initial pom.xml for you and keep adding as you bring in libraries without having manually add them. I have only recently begun using some Gradle builds after I hopped into an open source project that was using them and I'm quite impressed by the ease of it as well as the speed. You can have Gradle do a lot of the tasks you would've done with an Ant script + Maven pom. I'm already impressed with the lack of effort for sub-module builds, I've always found Maven to a pain for getting those working just right. Additionally, when you run the Gradle build daemon locally your builds are WAY faster than running Maven builds. I found the IntelliJ support for Gradle to be very good so far and I am going to continue to try converting a number of my existing projects over to Gradle as time allows. EDIT: The main thing I really need to investigate with Gradle is what it does that is similar to a parent pom in Maven. We make pretty extensive use of parent poms in order to reduce boilerplate and keep dependency versions in sync, and we use Artifactory for everything. EDIT2: This [0] Maven vs Gradle breakdown (though obviously pro-Gradle) highlights some areas where Gradle could really make a difference for people. [0] https://gradle.org/maven_vs_gradle/ https://gradle.org/maven_vs_gradle/
- GeneralTspoon 10y ago
  Regarding parent poms, you can do something similar in gradle with the top-level build.gradle file. Check out this project for an example of how that works: https://github.com/JakeWharton/butterknife https://github.com/JakeWharton/butterknife
- xirdstl 10y ago
  We created a number of Gradle plugins for our common boilerplate. We publish those as a JAR into our internal Artifactory, and they're easily applied to any of our modules.
- rdsubhas 10y ago
  In Maven, the only way to share build logic is through a parent POM. Even if only four modules (out of 10) need to share some build logic, the only way is to get it into the parent POM. So in most maven projects, the parent POM is a kitchen sink. Gradle allows to create separate shared ".gradle" files that individual projects can import. This is push vs pull, and makes a world of a difference. So we have one shared "java_service.gradle" and one shared "java_library.gradle", and our submodules just do "apply from: <shared-build-file>". Our root "build.gradle" is intentionally empty with a BIG warning never to add any shared logic in it. This is just one of the reasons. You also see that with gradle, you can do "gradle test" on one submodule and it will compile all other dependencies but run tests only on this module. Maven, on the other hand, if you do "mvn test --pl <module> --also-make", will compile and test ALL related modules. I can keep writing a long list of other stuff. But in the end, Maven is a "Project Management Tool" that tried to do a hundred things, and gets nothing right. Gradle is a proper good build tool.
Randgalt 10y ago
My view on the subject, FWIW: https://rule1.quora.com/Use-Maven-Not-Gradle https://rule1.quora.com/Use-Maven-Not-Gradle
- yoz-y 10y ago
  I must disagree with the notion that using Ant and Maven does not introduce a new language to the project. Using Ant does require you to learn a completely new language albeit one which follows the XML conventions. To say it is not new would be like comparing XHTML and XSLT, they are both XML and both are very different. I do not like the Gradle DSL because I find it chaotic and inconsistent, however sprinkling XML tags everywhere does not do much good for readability.
  - Randgalt 10y ago
    That's a fair point. Ant's XML usage is closer to a DSL than not. But, it's still much simpler than the various Gradle DSLs I've seen.
lomnakkus 10y ago
(All of this is IME, of course:) Maven is awful when you get to even moderately large projects -- there are many reasons (and I'm sure you can find them on the web). Yes, you can find heaps of documentation and StackOverflow answers which detail all the workarounds you'll need, but... wouldn't you rather have a system that didn't require huge amounts of documentation and workarounds in the first place? (Btw, I'm not saying Gradle is the system which transports you to this holy land. I personally think it's hugely better than Maven in every conceivable way, though. Except if "better at being Maven" is a consideration, obviously.)
fgonzag 10y ago
Gradle is the amazing middle ground between maven and ant. Highly customizable like ant, but with a ton of predefined behaviors like maven. Unlike maven though, changing or customizing predefined behaviors is a lot easier.

reitanqild 10y ago

It seems to me that gradle has a performance edge (things like incremental rebuilds etc) although I haven't used it so I cannot say for sure. My inner grumpy anti-hipster says it is mostly about riding the tail of the anti-xml wave though: "no xml? Then it must be good!"

pjmlp 10y ago
From my Android SDK experience, Ant and Maven are much faster than Gradle. If you check the developer Q&A videos at Google IO 2016, one of the issues that got discussed was precisely the slow builds. It is also interesting that they had to re-write the public API in Java for Gradle 3, as part of their speed improvements.
- darylteo 10y ago
  From what I know, the Groovy runtime was a constant-time bottle neck for all builds (time to initialise, interpret etc.), hence the perceived "slow builds" for any small to medium sized project.
- Eridrus 10y ago
  My experience is similar to yours - when not using the dragle daemon. IIRC the gradle daemon made things competetive if not faster, though it's been a while since I tried.
  - pjmlp 10y ago
    Yet Ant and Maven don't need a daemon to be fast. There is a recent post from the Android team, where they advise to allocate between 2 and 5 GBs for the daemon!
    - Eridrus 10y ago
      Wow, that's totally crazy. Is that due to Android projects needing to link against Android which is a very large library? I don't recall it being that dire for my non-Android project, but I don't recall checking my mem usage either...
      - pjmlp 10y ago
        Due to the DEX conversion.

manyxcxi 10y ago

One thing you will find in more complicated builds is that, short of writing your own Maven plugins, you will still need Ant scripts or at least some very arcane incantations of Maven to get the job done. I've used Maven for a long time and the vast majority of my projects are Maven based- for the ones that follow the archetype, Maven is a pretty easy fit. As a matter of fact if you've got an IDE like IntelliJ, it'll build your initial pom.xml for you and keep adding as you bring in libraries without having manually add them. I have only recently begun using some Gradle builds after I hopped into an open source project that was using them and I'm quite impressed by the ease of it as well as the speed. You can have Gradle do a lot of the tasks you would've done with an Ant script + Maven pom. I'm already impressed with the lack of effort for sub-module builds, I've always found Maven to a pain for getting those working just right. Additionally, when you run the Gradle build daemon locally your builds are WAY faster than running Maven builds. I found the IntelliJ support for Gradle to be very good so far and I am going to continue to try converting a number of my existing projects over to Gradle as time allows. EDIT: The main thing I really need to investigate with Gradle is what it does that is similar to a parent pom in Maven. We make pretty extensive use of parent poms in order to reduce boilerplate and keep dependency versions in sync, and we use Artifactory for everything. EDIT2: This [0] Maven vs Gradle breakdown (though obviously pro-Gradle) highlights some areas where Gradle could really make a difference for people. [0] https://gradle.org/maven_vs_gradle/ https://gradle.org/maven_vs_gradle/

GeneralTspoon 10y ago
Regarding parent poms, you can do something similar in gradle with the top-level build.gradle file. Check out this project for an example of how that works: https://github.com/JakeWharton/butterknife https://github.com/JakeWharton/butterknife
xirdstl 10y ago
We created a number of Gradle plugins for our common boilerplate. We publish those as a JAR into our internal Artifactory, and they're easily applied to any of our modules.
rdsubhas 10y ago
In Maven, the only way to share build logic is through a parent POM. Even if only four modules (out of 10) need to share some build logic, the only way is to get it into the parent POM. So in most maven projects, the parent POM is a kitchen sink. Gradle allows to create separate shared ".gradle" files that individual projects can import. This is push vs pull, and makes a world of a difference. So we have one shared "java_service.gradle" and one shared "java_library.gradle", and our submodules just do "apply from: <shared-build-file>". Our root "build.gradle" is intentionally empty with a BIG warning never to add any shared logic in it. This is just one of the reasons. You also see that with gradle, you can do "gradle test" on one submodule and it will compile all other dependencies but run tests only on this module. Maven, on the other hand, if you do "mvn test --pl <module> --also-make", will compile and test ALL related modules. I can keep writing a long list of other stuff. But in the end, Maven is a "Project Management Tool" that tried to do a hundred things, and gets nothing right. Gradle is a proper good build tool.

Randgalt 10y ago

My view on the subject, FWIW: https://rule1.quora.com/Use-Maven-Not-Gradle https://rule1.quora.com/Use-Maven-Not-Gradle

yoz-y 10y ago
I must disagree with the notion that using Ant and Maven does not introduce a new language to the project. Using Ant does require you to learn a completely new language albeit one which follows the XML conventions. To say it is not new would be like comparing XHTML and XSLT, they are both XML and both are very different. I do not like the Gradle DSL because I find it chaotic and inconsistent, however sprinkling XML tags everywhere does not do much good for readability.
- Randgalt 10y ago
  That's a fair point. Ant's XML usage is closer to a DSL than not. But, it's still much simpler than the various Gradle DSLs I've seen.

lomnakkus 10y ago

(All of this is IME, of course:) Maven is awful when you get to even moderately large projects -- there are many reasons (and I'm sure you can find them on the web). Yes, you can find heaps of documentation and StackOverflow answers which detail all the workarounds you'll need, but... wouldn't you rather have a system that didn't require huge amounts of documentation and workarounds in the first place? (Btw, I'm not saying Gradle is the system which transports you to this holy land. I personally think it's hugely better than Maven in every conceivable way, though. Except if "better at being Maven" is a consideration, obviously.)

fgonzag 10y ago

Gradle is the amazing middle ground between maven and ant. Highly customizable like ant, but with a ton of predefined behaviors like maven. Unlike maven though, changing or customizing predefined behaviors is a lot easier.