Maven (and pretty much every other build tool with the exception of bazel) is not capable enough for such a complex build as is required for android, though. E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts. Gradle can always keeps track of tasks correctly.
Maven (and pretty much every other build tool with the exception of bazel) is not capable enough for such a complex build as is required for android, though.
Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration...
> E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts.
This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything…
> Gradle can always keeps track of tasks correctly.
LOL, from my experience that is not true.
Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
> Maven is virtually infinite extensibility via plugins
Losing the only task of a build tool, caching and parallelization.
No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph?
> LOL, from my experience that is not true
In what way is it not true?
Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
And multiple daemons — you can disable them, and they will go away if unused.
> Losing the only task of a build tool, caching and parallelization.
You are aware that Maven does offer paralle build, right?
> I guess maven just doesn’t have an accurate build graph?
You guess wrong? then
>> LOL, from my experience that is not true
> In what way is it not true?
Consistency of gradle build. You yourself stated just a paragraph above that sometimes you have to run "clean" xD
> Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
Again, learn the tool. Maven does offer parallel builds and is comparably fast…
> And multiple daemons — you can disable them, and they will go away if unused.
"but you are turning off the only feature of a build!!!"
Also - I had a setup open with gradle/kotlin-multiplatform project (shell with "gradlew" and Android Studio) and magically it fails to build with "Unresolved reference: kotlinx" even though I haven't done anything to the project and no ammount of running "gradlew clean" solves it... what a lovely tool....
I tried and
* commons took more than 2,5 minutes to build (they show 70s?)
* tried their tests (medium project, https://github.com/gradle/performance-comparisons/tree/maste...) and maven compiled it in 4s and usual "clean install" took 14s but they don't enable paralel test run); then I tried running "gradle build" and... got an error:
* What went wrong:
A problem occurred evaluating root project 'single-medium-project'.
> Could not find method compile() for arguments [commons-lang:commons-lang:2.5] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
```
It's so nice that even gradle team themselves can keep up with their crap xD but of course it's probably due to convoluted setup... again - with maven you just clone and build and be done with it, with gradle you have to "stand on your head" to figure how to make any progress... I updated the build.gradle (according to https://docs.gradle.org/current/userguide/declaring_dependen...) and `gradle build` finished in 19s...
So your beloved gradle is 25% slower and can't even be compatible with itself...
I took a look at "large-multimodule" to have something more challenging but: they setup each project individually and for some convoluted reason configure maven compiler with `<source>1.5</source>` (and JDK21 complains) and same goes for gradle modules with broken `dependencies`. I adjusted it but then it turned out that the sources can't even compile (due to wrong arguments in tests) ffs...
Maven is more as capable for anyone that doesn't suffer from XML allergy, and doesn't require a background daemon to actually make it run at reasonable speed.
Correctness is the number 1 priority, and maven is simply not always doing what it should, unless you do a clean build.
I am absolutely not bothered by XML and alia (btw, there are maven frontends in json/yaml, etc for those who are), and throwing out valid criticism over some straw man is not really productive.
I’m still learning about the tools and their pros and cons. Can you provide an example of a case where Maven would not do what it should? Are there particular bug reports or bug reproduction repos that you’ve seen?
Context: I worked on a Spring app many years ago and am picking Java back up.
But I have run into issues with multi-module projects and the like, and it can be very frustrating to realize that you are trying out some corrupt version. Nonetheless, maven is also a cool and stable tool, but you are better off adding a clean step from time to time.
