6 ms·

Can someone explain to me why Gradle is popular? It seems like hot garbage even though most teams can make it work. Maven was painful as well but it felt more

by jayd16 6y ago

Can someone explain to me why Gradle is popular? It seems like hot garbage even though most teams can make it work. Maven was painful as well but it felt more consistent to me. You know whats really sad? MsBuild proj and solution files are easier to understand! I'm sure there's a lot of great work that's going into Gradle but I just don't understand why this is the DSL and syntax we decided to put effort into.

gozzoo 6y ago
Because it fixes some of the problems of Maven, which was the defacto standard in the Java world, and is quite horrible. Gradle is to Maven what svn was to cvs.
- pjmlp 6y ago
  What problems? The only one is XML allergy.
  - jayd16 6y ago
    I've seen people claim Gradle is language agnostic and Maven isn't. Not sure I agree but its what I'm told...
    - jdmichal 6y ago
      Maven defaults to Java, but I'm pretty sure there's compilation plugins for all the JVM languages.
  - blktiger 6y ago
    Speed - a gradle build computes hashes of all the build steps so it knows when to skip things that don’t need to be run. Spring converted their builds to gradle and were able to cut their builds from an hour to 10 minutes (full-ci bulds). https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle https://spring.io/blog/2020/06/08/migrating-spring-boot-s-bu...
    - pjmlp 6y ago
      After getting several GB allocated to the Gradle daemon and using SSDs, I would bet.
  - gozzoo 6y ago
    Actually XML is the smaler problem. Maven forces you to use a predifened structure for your project. The more some project deviates from Maven's assumptions about how it should be organized, the more complicated the pom file becomes. For each medium sized project I've seen it looks completely uncomprehendable. Usually there was only one member in the team who can touch it.
    - pjmlp 6y ago
      Which is a very good thing, Gradle is back into Ant cowboy land. Ever managed to understand Gradle complex files? There is a full application living there.
      - gozzoo 6y ago
        > Ever managed to understand Gradle complex files? Well, there is a funny annecdote I can share. In some presentation a guy was showing how you can implemnent some non trivial functionality for a Android app. He was very proud to demonstrate how it can be implemented in just few lines of code. Then he showed casually just for few sec the gradle file for the demo app, which was about 50 lines. We were joking how simple and easy things can be as long you are gradle magician.
  - twic 6y ago
    Maven is overly rigid. Years ago, i worked on a project where it made sense to have two integration test tasks - main tests and some special separate set of tests, i forget why. In Gradle, that's trivial. In Maven, it is impossible. You would have to write a new plugin which duplicates the existing integration test plugin to do it. Maven runs the stages of the build in a fixed order, defined by the plugin code. If you have a reason to run two stages in a different order, bad luck, that can't be done. There are tons of things like this.
    - jdmichal 6y ago
      I'm pretty sure I've done this before... Maven is generally nothing more than some plugin executions with default configurations bound to specific phases. Both `surefire` and `failsafe` plugins allow you to configure the pattern of files executed (via `includes`). So you should be able to easily configure three executions, all with mutually-exclusive file patterns, one unit-test and two integration-tests. And you can choose whether or not to bind them to phases or run them manually.
pjmlp 6y ago
It has Google's Android team as sponsor that has decided to push it no matter what, which act as if there was no other alternative to Ant available. Ironically even Google own teams rather use Basel and Soong as the Gradle based builds that the Android team imposes to everyone else using the Android SDK.
zmmmmm 6y ago
I reckon the best thing gradle ever did was the 'gradle wrapper' which means, if you have just java installed it'll bootstrap everything up from nothing. So if starting a new project and I just want people to be able to build it and I want them to use exactly a specific version of gradle I can create a 1 line build file and it works for just about anybody who runs it on any platform. So on the one hand, its the easiest way to get started, and on the other hand its a turing complete language so there isn't anything it can't do so once started, people can always keep going. And then, yes, Maven is complex and mysterious in completely different ways but almost to the same extent as Gradle.
- wasyl 6y ago
  Coming from Gradle, it always baffles me how there's no wrapper for every popular tool out there. I'm always confused by the venvs, rbenvs, and overall managing multiple versions of the toolchain for different projects. In Gradle it's just so simple, and with toolchains support [1] it's going to be a very predictable build environment with just a simple `./gradlew` invocation. [1] https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html
  - Tainnor 6y ago
    tl;dr I think that especially compared to Python with its... very fragmented landscape of dependency and version management tools, Ruby has a pretty standardised way of making sure you run everything in a reproducible environment, which maybe isn't 100% perfect, but usually works quite fine, even though it is a different approach than the gradle wrapper. -- More details: In Ruby, it is by now completely standard practice to use some sort of Ruby version manager (rbenv, rvm, chruby, for example - they should all work). Those version managers always can pick up the correct Ruby version from the ".ruby-version" file. This is actually an improvement over the Java situation where different people might in theory run the same project with different versions of the JDK without them even noticing (although the JVM is of course much more backwards-compatible than Ruby usually is, but it can still lead to problems). Even the gradle wrapper doesn't help you there - it assumes you already have the JDK installed. Also, Gemfiles (dependency declaration files) typically (or maybe nowadays always?) include the version of Ruby used, and the Gemfile.lock also specifies the version of Bundler that was used. It is standard practice to run every Ruby command in a project through "bundle exec", in which case Bundler will always check all your dependency versions. If the Ruby version is wrong (which can only happen if you don't use a version manager anyway), I think it will just refuse to run and print an error message, same if you haven't installed some dependency with the right version. If the bundler version doesn't match, I think it will at least output a warning in some cases. So, in practice, the only true differences between that and the gradle wrapper are: - you need to install bundler yourself (although that's just "gem install bundler") - you need to remember to use "bundle exec" (although there are tricks to avoid that, e.g. binstubs + something like direnv) - you might not use the "right" bundler version, unlike with Gradle - however, in several years of writing Ruby I ran into the problem that a mismatched Bundler version led to an issue, exactly once - and they've since added the warning - so I don't think it's that big of a deal - on the plus side for Bundler, it actually enforces transitive dependency locking, unlike Gradle, for which you have to explicitly enable it - and also many other tools don't support that properly (e.g. Dependabot)
mr_tristan 6y ago
I suspect that Android and Kotlin have really helped Gradle adoption. But even before this, Gradle has a very easy "customize it" approach. Though... honestly, it might just be that people hate XML. Personally, I've stuck with Gradle, even though I'm not really happy with it, mostly because of these features: 1. Composite builds - https://docs.gradle.org/current/userguide/composite_builds.html https://docs.gradle.org/current/userguide/composite_builds.h... 2. Dependency substitution 3. "local" plugins, i.e., stuff in `./buildSrc` These features let me combine projects defined in multiple git repositories in a "workspace" project. Then IntelliJ can read all these projects, and it magically substitutes my local version over a specific version. Ergo, I can have multiple libraries, edit and debug them and and application code. When it's time to commit, I push them up in individual MRs back in GitLab - And I could swear GitLab was going to make some kind of multi-project MR possible at some point. So, the "workspace" is generally for development, then we use GitLab CI for each project independently, for a "formal" versioned approach. It's quite nice. In any case, I'll typically work with a pretty broad set of apps and libraries in a single workspace, typically between 15-30, and Gradle and IntelliJ handle this just fine. Our Maven projects with fewer modules never seem to get things working as smoothly ironed out - I suspect it's something wacky going on with the build. So, while Maven allows build composition, but doesn't really have the dependency substitution concept, useful for local workflows. Also, it just doesn't seem to perform as well, especially with the IDEs we've been using. I can't explain it, haven't investigated it, but then again, I've found a solution that works.
- lmz 6y ago
  That's really nice. Does maven support anything similar? Last time I tried this in maven it devolved into playing weird tricks with the local cache (custom versions and mvn install) for the included dependencies that I wanted to change.
  - mr_tristan 6y ago
    AFAIK, Maven allows you to reference multiple builds like the Gradle composite build feature, but, I don't know of any kind of official dependency substitution mechanism. I'm very far from a Maven specialist, though. I suspect with Maven this would require some plugin work.

by jayd16 6y ago

gozzoo 6y ago

Because it fixes some of the problems of Maven, which was the defacto standard in the Java world, and is quite horrible. Gradle is to Maven what svn was to cvs.

pjmlp 6y ago
What problems? The only one is XML allergy.
- jayd16 6y ago
  I've seen people claim Gradle is language agnostic and Maven isn't. Not sure I agree but its what I'm told...
  - jdmichal 6y ago
    Maven defaults to Java, but I'm pretty sure there's compilation plugins for all the JVM languages.
- blktiger 6y ago
  Speed - a gradle build computes hashes of all the build steps so it knows when to skip things that don’t need to be run. Spring converted their builds to gradle and were able to cut their builds from an hour to 10 minutes (full-ci bulds). https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle https://spring.io/blog/2020/06/08/migrating-spring-boot-s-bu...
  - pjmlp 6y ago
    After getting several GB allocated to the Gradle daemon and using SSDs, I would bet.
- gozzoo 6y ago
  Actually XML is the smaler problem. Maven forces you to use a predifened structure for your project. The more some project deviates from Maven's assumptions about how it should be organized, the more complicated the pom file becomes. For each medium sized project I've seen it looks completely uncomprehendable. Usually there was only one member in the team who can touch it.
  - pjmlp 6y ago
    Which is a very good thing, Gradle is back into Ant cowboy land. Ever managed to understand Gradle complex files? There is a full application living there.
    - gozzoo 6y ago
      > Ever managed to understand Gradle complex files? Well, there is a funny annecdote I can share. In some presentation a guy was showing how you can implemnent some non trivial functionality for a Android app. He was very proud to demonstrate how it can be implemented in just few lines of code. Then he showed casually just for few sec the gradle file for the demo app, which was about 50 lines. We were joking how simple and easy things can be as long you are gradle magician.
- twic 6y ago
  Maven is overly rigid. Years ago, i worked on a project where it made sense to have two integration test tasks - main tests and some special separate set of tests, i forget why. In Gradle, that's trivial. In Maven, it is impossible. You would have to write a new plugin which duplicates the existing integration test plugin to do it. Maven runs the stages of the build in a fixed order, defined by the plugin code. If you have a reason to run two stages in a different order, bad luck, that can't be done. There are tons of things like this.
  - jdmichal 6y ago
    I'm pretty sure I've done this before... Maven is generally nothing more than some plugin executions with default configurations bound to specific phases. Both `surefire` and `failsafe` plugins allow you to configure the pattern of files executed (via `includes`). So you should be able to easily configure three executions, all with mutually-exclusive file patterns, one unit-test and two integration-tests. And you can choose whether or not to bind them to phases or run them manually.

pjmlp 6y ago

It has Google's Android team as sponsor that has decided to push it no matter what, which act as if there was no other alternative to Ant available. Ironically even Google own teams rather use Basel and Soong as the Gradle based builds that the Android team imposes to everyone else using the Android SDK.

zmmmmm 6y ago

I reckon the best thing gradle ever did was the 'gradle wrapper' which means, if you have just java installed it'll bootstrap everything up from nothing. So if starting a new project and I just want people to be able to build it and I want them to use exactly a specific version of gradle I can create a 1 line build file and it works for just about anybody who runs it on any platform. So on the one hand, its the easiest way to get started, and on the other hand its a turing complete language so there isn't anything it can't do so once started, people can always keep going. And then, yes, Maven is complex and mysterious in completely different ways but almost to the same extent as Gradle.

wasyl 6y ago
Coming from Gradle, it always baffles me how there's no wrapper for every popular tool out there. I'm always confused by the venvs, rbenvs, and overall managing multiple versions of the toolchain for different projects. In Gradle it's just so simple, and with toolchains support [1] it's going to be a very predictable build environment with just a simple `./gradlew` invocation. [1] https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html
- Tainnor 6y ago
  tl;dr I think that especially compared to Python with its... very fragmented landscape of dependency and version management tools, Ruby has a pretty standardised way of making sure you run everything in a reproducible environment, which maybe isn't 100% perfect, but usually works quite fine, even though it is a different approach than the gradle wrapper. -- More details: In Ruby, it is by now completely standard practice to use some sort of Ruby version manager (rbenv, rvm, chruby, for example - they should all work). Those version managers always can pick up the correct Ruby version from the ".ruby-version" file. This is actually an improvement over the Java situation where different people might in theory run the same project with different versions of the JDK without them even noticing (although the JVM is of course much more backwards-compatible than Ruby usually is, but it can still lead to problems). Even the gradle wrapper doesn't help you there - it assumes you already have the JDK installed. Also, Gemfiles (dependency declaration files) typically (or maybe nowadays always?) include the version of Ruby used, and the Gemfile.lock also specifies the version of Bundler that was used. It is standard practice to run every Ruby command in a project through "bundle exec", in which case Bundler will always check all your dependency versions. If the Ruby version is wrong (which can only happen if you don't use a version manager anyway), I think it will just refuse to run and print an error message, same if you haven't installed some dependency with the right version. If the bundler version doesn't match, I think it will at least output a warning in some cases. So, in practice, the only true differences between that and the gradle wrapper are: - you need to install bundler yourself (although that's just "gem install bundler") - you need to remember to use "bundle exec" (although there are tricks to avoid that, e.g. binstubs + something like direnv) - you might not use the "right" bundler version, unlike with Gradle - however, in several years of writing Ruby I ran into the problem that a mismatched Bundler version led to an issue, exactly once - and they've since added the warning - so I don't think it's that big of a deal - on the plus side for Bundler, it actually enforces transitive dependency locking, unlike Gradle, for which you have to explicitly enable it - and also many other tools don't support that properly (e.g. Dependabot)

mr_tristan 6y ago

I suspect that Android and Kotlin have really helped Gradle adoption. But even before this, Gradle has a very easy "customize it" approach. Though... honestly, it might just be that people hate XML. Personally, I've stuck with Gradle, even though I'm not really happy with it, mostly because of these features: 1. Composite builds - https://docs.gradle.org/current/userguide/composite_builds.html https://docs.gradle.org/current/userguide/composite_builds.h... 2. Dependency substitution 3. "local" plugins, i.e., stuff in `./buildSrc` These features let me combine projects defined in multiple git repositories in a "workspace" project. Then IntelliJ can read all these projects, and it magically substitutes my local version over a specific version. Ergo, I can have multiple libraries, edit and debug them and and application code. When it's time to commit, I push them up in individual MRs back in GitLab - And I could swear GitLab was going to make some kind of multi-project MR possible at some point. So, the "workspace" is generally for development, then we use GitLab CI for each project independently, for a "formal" versioned approach. It's quite nice. In any case, I'll typically work with a pretty broad set of apps and libraries in a single workspace, typically between 15-30, and Gradle and IntelliJ handle this just fine. Our Maven projects with fewer modules never seem to get things working as smoothly ironed out - I suspect it's something wacky going on with the build. So, while Maven allows build composition, but doesn't really have the dependency substitution concept, useful for local workflows. Also, it just doesn't seem to perform as well, especially with the IDEs we've been using. I can't explain it, haven't investigated it, but then again, I've found a solution that works.

lmz 6y ago
That's really nice. Does maven support anything similar? Last time I tried this in maven it devolved into playing weird tricks with the local cache (custom versions and mvn install) for the included dependencies that I wanted to change.
- mr_tristan 6y ago
  AFAIK, Maven allows you to reference multiple builds like the Gradle composite build feature, but, I don't know of any kind of official dependency substitution mechanism. I'm very far from a Maven specialist, though. I suspect with Maven this would require some plugin work.