5 ms·

I never understood why one would want to use Gradle over Maven. Gradle seems like a very complicated way to avoid using XML as configuration and essentially end

I never understood why one would want to use Gradle over Maven. Gradle seems like a very complicated way to avoid using XML as configuration and essentially end up with Ant.

ptx 6y ago
One big advantage is the Gradle daemon, which (in return for consuming all available memory) saves you from having to spin up the JVM every time you build and can be substantially faster. It seems someone has recently created something similar for Maven: https://github.com/mvndaemon/mvnd https://github.com/mvndaemon/mvnd
- cratermoon 6y ago
  > saves you from having to spin up the JVM every time you build Too bad most CI/CD pipelines are effectively stateless, spinning up a new vm, docker image, or whatever for every run. Gradle's cold startup time is awful now that they've pushed more and more into the deamon, make it a major bottleneck in build times.
  - kaba0 6y ago
    Does it really matter how long CI build takes (in terms of it being a few percent slower/faster)? And incremental builds when one develops does boost performance significantly.
    - lmm 6y ago
      For local development you're using your IDE to build, no? (At least if your IDE understands your build definition, which is always with Maven and sometimes with Gradle). So CI is the only case where the speed of the command-line build matters.
      - kaba0 6y ago
        And what do you think your IDE calls? Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy.
        lmm 6y ago
        > And what do you think your IDE calls? The IDE doesn't invoke the build tool, it extracts the project structure from it. If the build tools has a sane model (i.e. maven or a gradle build that's maintained with discipline) then it will get an accurate picture of which sources should be built depending on which other ones, and can use that combined with its own knowledge of which files have been edited to do incremental compilation and even e.g. re-run affected unit tests but not others. > Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy. Using incremental compilation for release artifacts is a huge red flag IMO - how will you reproduce that same build in the future? So using it for local builds is a tradeoff: you get to iterate faster, but you have a divergence between your release build and the one you're iterating with. IME it's usually worthwhile (provided you're still running your full test suite as part of your release build). So given that there's going to be a different code path running, is it important to be using the same build tool in those two cases? IMO no - the difference between maven building my code for release and my IDE building my code incrementally based on my maven project model isn't really any bigger than the difference between gradle building my code for release vs gradle building my code incrementally. If anything the fact that maven exposes the project model in a stable form (such that my IDE is able to use it) is an argument that those builds will be more consistent.
        kaba0 6y ago
        But you can use gradle to build from an IDE and gradle will do incremental builds correctly and fastly (as opposed to maven where you should be doing clean install).
        6y ago
    - cratermoon 6y ago
      If it were a few percent, it would matter, over days and weeks of development. But it's not a few percent. The difference between spinning up gradle from scratch to gradle using a running daemon is substantial. You can cough up money and resources for their Enterprise edition to get the shared build server, but you add an incredible amount of complexity and difficulties with reproducibility.
      - kaba0 6y ago
        Actually, gradle will be likely faster even without the daemon as it can parallelize tasks (as opposed to maven that can only parallelize multi-repo projects)
vbezhenar 6y ago
Gradle properly supports multi project build. Maven support is just weird.
- miked85 6y ago
  Probably because it doesn't really make sense. If you have to build multiple projects as part of your build, they should probably be in the same repository, or you should be consuming artifacts already created from other project builds.
  - vbezhenar 6y ago
    They are in the same repository. For example with Maven if you run any task from the sub-project which depends on adjacent sub-project, maven will look for it in ~/.m2/repository. So you have to mvn install every time you're doing any change in any sub-project which is PITA when you're changing many sub-projects simultaneously (and if you did not mvn install, you'll have old version in repository and new sources in IDE and things go wrong way in a completely non-obvious manner). But if you're running maven commands from root pom, sub-projects will properly reference each other. So the proper way is to run all commands from root repository and specify -pl. But then you'll run into other issues, as not all plugins will work correctly this way (for example mvn exec:java). With gradle it just works. You're running command for any sub-project and gradle will properly find any dependant sub-projects, build them, put them into classpath, etc.

I never understood why one would want to use Gradle over Maven. Gradle seems like a very complicated way to avoid using XML as configuration and essentially end up with Ant.

ptx 6y ago

One big advantage is the Gradle daemon, which (in return for consuming all available memory) saves you from having to spin up the JVM every time you build and can be substantially faster. It seems someone has recently created something similar for Maven: https://github.com/mvndaemon/mvnd https://github.com/mvndaemon/mvnd

cratermoon 6y ago
> saves you from having to spin up the JVM every time you build Too bad most CI/CD pipelines are effectively stateless, spinning up a new vm, docker image, or whatever for every run. Gradle's cold startup time is awful now that they've pushed more and more into the deamon, make it a major bottleneck in build times.
- kaba0 6y ago
  Does it really matter how long CI build takes (in terms of it being a few percent slower/faster)? And incremental builds when one develops does boost performance significantly.
  - lmm 6y ago
    For local development you're using your IDE to build, no? (At least if your IDE understands your build definition, which is always with Maven and sometimes with Gradle). So CI is the only case where the speed of the command-line build matters.
    - kaba0 6y ago
      And what do you think your IDE calls? Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy.
      - lmm 6y ago
        > And what do you think your IDE calls? The IDE doesn't invoke the build tool, it extracts the project structure from it. If the build tools has a sane model (i.e. maven or a gradle build that's maintained with discipline) then it will get an accurate picture of which sources should be built depending on which other ones, and can use that combined with its own knowledge of which files have been edited to do incremental compilation and even e.g. re-run affected unit tests but not others. > Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy. Using incremental compilation for release artifacts is a huge red flag IMO - how will you reproduce that same build in the future? So using it for local builds is a tradeoff: you get to iterate faster, but you have a divergence between your release build and the one you're iterating with. IME it's usually worthwhile (provided you're still running your full test suite as part of your release build). So given that there's going to be a different code path running, is it important to be using the same build tool in those two cases? IMO no - the difference between maven building my code for release and my IDE building my code incrementally based on my maven project model isn't really any bigger than the difference between gradle building my code for release vs gradle building my code incrementally. If anything the fact that maven exposes the project model in a stable form (such that my IDE is able to use it) is an argument that those builds will be more consistent.
        kaba0 6y ago
        But you can use gradle to build from an IDE and gradle will do incremental builds correctly and fastly (as opposed to maven where you should be doing clean install).
        6y ago
  - cratermoon 6y ago
    If it were a few percent, it would matter, over days and weeks of development. But it's not a few percent. The difference between spinning up gradle from scratch to gradle using a running daemon is substantial. You can cough up money and resources for their Enterprise edition to get the shared build server, but you add an incredible amount of complexity and difficulties with reproducibility.
    - kaba0 6y ago
      Actually, gradle will be likely faster even without the daemon as it can parallelize tasks (as opposed to maven that can only parallelize multi-repo projects)

vbezhenar 6y ago

Gradle properly supports multi project build. Maven support is just weird.

miked85 6y ago
Probably because it doesn't really make sense. If you have to build multiple projects as part of your build, they should probably be in the same repository, or you should be consuming artifacts already created from other project builds.
- vbezhenar 6y ago
  They are in the same repository. For example with Maven if you run any task from the sub-project which depends on adjacent sub-project, maven will look for it in ~/.m2/repository. So you have to mvn install every time you're doing any change in any sub-project which is PITA when you're changing many sub-projects simultaneously (and if you did not mvn install, you'll have old version in repository and new sources in IDE and things go wrong way in a completely non-obvious manner). But if you're running maven commands from root pom, sub-projects will properly reference each other. So the proper way is to run all commands from root repository and specify -pl. But then you'll run into other issues, as not all plugins will work correctly this way (for example mvn exec:java). With gradle it just works. You're running command for any sub-project and gradle will properly find any dependant sub-projects, build them, put them into classpath, etc.