> Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer.

I experienced the opposite, that even simple things require quite complex configuration in maven. I was shocked by how difficult shading is.

Gradle and SBT gave some confusion, but a great deal less than maven.

> even simple things require quite complex configuration in maven.

I have used Maven on and off since around 2007/2008 sometime.

Since I started taking responsibility for build setups I have realized that I think in every single case where I found unexpected complexity in Maven it could be solved by something like putting some folder or file in the place it was supposed to be all the time and delete most of the configuration.

Convention over configuration is central to Maven after all and extra configuration is only necessary if you do something non standard.

Maven is very slow in big, multi module projects. Gradle can cache module results (avoiding rebuilding), test results and can distribute build artifacts between developers

> and can distribute build artifacts between developers

You care to elaborate on this point? Seems a bit too terse to convey whatever benefit this provides?

I would have thought an artefact repo solves this?

given a project split in several modules, we don't want to build them separately, we want to type check at compile time that everything works and we have a single build system managed by Gradle. Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them.

The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache.

* Developer 1 changes module A * code is pushed * CI pipeline is running and uploading all the artifacts (final production code, final test code, test results) * Developer 2 pull code locally * gradle find changes from the last local run, it tries to compile/run the tests of updated modules but results are downloaded from the cache, instead of running locally

> Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them.

I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it?

> The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache.

But why should other developers have a relation to the source of dependencies except for debugging?

Isn't it better to upload the packaged jars to some kind of artifact repository at the end of their build pipeline?

> I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it?

for example when when you change an api module in a multi module project, gradle will rebuild/test all the modules that depends on that: you can't do automatically with maven, if you have separate artifacts shared via a repository (at least for my understanding). You can use a reactor module, but maven is not caching efficiently in local builds and not caching at all from a common, distributed cache.

> But why should other developers have a relation to the source of dependencies except for debugging?

Because in a multi module project, each developer has access to the complete project source code and can change whatever module: this is the whole idea of the setup (monorepo idea as Google, for example). In this scenario it is possible to have fine grained module boundaries without the cost of creating new project or the evolution of the interface. If a module doesn't provide the information needed it is easy to change it and gradle will rebuild everything that depends on that. If a new module is needed, it is just a new directory with a build.gradle file in it.

Just to be clear, the end result of a multi module project, at least in my setup, is the creation of single artifact that is going to be deployed.

Thanks, I guess I am underestimating the complexities of monorepos.

If you need more speed, you can use

https://github.com/apache/maven-mvnd

Yes, in Maven its often much easier to align the project to Maven's conventions than to fight it.

... and Mavens conventions are so common that by doing so, many other details fall in place automatically as well.

Besides I haven't seen anyone presenting any conventions that I would rather use, even if it would magically work in Maven and across all IDEs.

My first experience with maven was the same. Then I learned what project structure , what plugin and dependency management it expects. I also read a 90 page long introduction book from cover to cover. I don't have problems with it since and every project I meet is familiar in an instant.

I like maven.

I've seems hundreds of different projects using Maven and more or less every pom.xml looked the same. Onboarding took minutes.

The first few Gradle projects I've seen looked completely different, one project contained more Gradle configuration than actual source code.

And it becomes worse and worse, as every major Gradle version adds new stuff on top.

I can also checkout an old Maven project and it will probably work with a recent Maven version.

With Gradle, not so much. Breaking changes left and right...

It's sort of clicked for me.

I've managed to make something that's actually makes Gradle seem pretty impressive, I think mostly by accident. I recently migrated Marginalia's code base to a highly modular set-up, and to my surprise Gradle actually does an extremely good job at dealing with this. Once I got it all set up, each sub module has a fairly clean gradle file that mostly just specifies dependencies and build artifacts. I can specify versions in a single file, dependency management is very straight forward and it's stupidly fast do incremental re-builds.

But to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style.

Although this is the first time I think I've begun to glimpse why Gradle exists other than to torment developers with API incompatibilities upon each (mandatory) upgrade to keep it working with the newest JVM.

> That said, to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style.

The now default Kotlin syntax helps somewhat.

How?? It's exactly the same as the Groovy syntax in almost every way, specially the nested blocks which makes Groovy look declarative and that Kotlin inherited from Groovy.

Better IDE autocomplete.

But then again you are the Swede that for a long time ran an advanced, publicly available search engine out of your living room as a side project while working full time.

Of course you can get Gradle to work.

Also even considering the above I'd say you were a bit lucky in that you could set up everything yourself, instead of having 11 different people on 7 different teams do it for you ;-)