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.
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.
> 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.
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.
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)
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.
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.
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.
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).
> 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.
I do agree that it is harder to correctly parse/import a gradle project into an IDE (though I haven’t got a bad experience lately), but when running the actual build tool, gradle will correctly identify previously compiled files and the like, and clean is absolutely not required. It is not true of maven.
But I do apologize, in my prev-prev reply I was way too cocky and wrong; actually building with the IDE is much more common (but depending on the project it can introduce subtle bugs, so do try out the build tool built version as well from time to time)
And build speed on large projects do matter, so there is a point where I think gradle is worth using over maven, because it can mean an order of magnitude reduction in build time.
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.
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.
