4 ms·

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 c

by 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).
        lmm 6y ago
        > But you can use gradle to build from an IDE and gradle will do incremental builds Not true in my experience. For a gradle project intellij offers me the choice of building with intellij (incorrect) or gradle (slow - the actual compilation may be fast and incremental, but it takes a couple of minutes to start up, build the project definition, and so on. I'm sure this is because me and my colleagues are using it wrong and some theoretical gradle wizard wouldn't have this problem, but it's been the behaviour of every gradle build I've had to use in actual real life). > correctly and fastly (as opposed to maven where you should be doing clean install) Not my experience at all. Maven may be less incremental but miscompilation is a lot more common with gradle. And more to the point, IDE-based build is a lot more reliable with maven than with gradle, to the point that any slowness of the maven-based build is irrelevant.
  - 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)

by ptx 6y ago

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).
        lmm 6y ago
        > But you can use gradle to build from an IDE and gradle will do incremental builds Not true in my experience. For a gradle project intellij offers me the choice of building with intellij (incorrect) or gradle (slow - the actual compilation may be fast and incremental, but it takes a couple of minutes to start up, build the project definition, and so on. I'm sure this is because me and my colleagues are using it wrong and some theoretical gradle wizard wouldn't have this problem, but it's been the behaviour of every gradle build I've had to use in actual real life). > correctly and fastly (as opposed to maven where you should be doing clean install) Not my experience at all. Maven may be less incremental but miscompilation is a lot more common with gradle. And more to the point, IDE-based build is a lot more reliable with maven than with gradle, to the point that any slowness of the maven-based build is irrelevant.
- 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)