Switch the default project type to Gradle

It’s the start.spring.io team’s opinion that, for anyone starting a project today, Gradle is the better build system to use. This is particularly true for Spring Boot 3.0-based applications where the developer experience with AOT processing is quite a bit better with Gradle. We’d like to nudge the community towards using Gradle while ensuring that Maven’s only a click away for those that prefer it.

For anyone who’d like Maven to always be their default, you can access start.spring.io using https://start.spring.io/#!type=maven-project. type isn’t the only parameter that’s supported. You can also change the Java version, language, packaging, etc via the URL. You can use the Share button to generate a URL and then just keep the bits that you always want to use by default.

[simasch]

Why do you think that Gradle is the better build system? In my opinion, Maven is much easier to use and less confusing, especially for beginners.

[melix]

Why do you think that Gradle is the better build system?

In order to be able to say what is “better”, we need to qualify better. I wouldn’t say Gradle is absolutely better, but it does beat Maven in a lot of areas. We should try to be as factual as possible, when we want to compare.

In my opinion, Maven is much easier to use and less confusing, especially for beginners.

Let me disagree with that and illustrate with a few areas Gradle is objectively better than Maven. First of all, I think we all agree that Maven is more widely used than Gradle. As a consequence, there is a habit bias, that is, you know the tool, so you can “more easily” use it: you know the commands, you are used to reading a POM file, etc. A second bias is that that tool has been around for years, so lots of processes are built around Maven specifics. It is no surprise, for example, that it is so hard for folks to stop calling mvn clean install. That’s the consequence of a tool which, for years, has been unreliable if you didn’t do a clean before install. Of course, you will find vocal folks saying “you don’t need clean anymore”, but this is not quite correct. Gradle doesn’t have such issues, because it’s a fully incremental build system. In Gradle, everything has declared inputs and outputs, so whenever you execute a command, Gradle knows exactly what to re-execute or not, including deleting stale files if needed. Gradle also provides incremental compilation for Java (and Groovy), as well as compilation avoidance (to avoid rebuilding downstream projects if they didn’t change). In general, Gradle is much faster than Maven, and things get even more interesting with the Gradle build cache.

Gradle also solves long standing issues like classpath pollution (e.g, the fact that you declare a dependency in the compile scope makes it available to your consumers even if it was an implementation detail which shouldn’t leak in your public API.

In terms of build structure, modern Gradle builds are significantly better designed than what it used to be with older releases. Gradle fixes the infamous single inheritance model from Maven, by favoriting composition over inheritance.

Gradle can also react to the application of other plugins, making it highly composable and reusable. I’m not even mentioning the fact that your build logic itself can be tested, which is a huge win. Let me illustrate with how Micronaut uses convention plugins so that every single project in Micronaut is configured the same, without cognitive overhead: a project tells what it is (a BOM), not how to build.

Gradle is also highly focused on developer productivity. For example, the continuous mode, which continuously monitors for changes in your sources and re-executes immediately tasks (compilation, tests), is a game changer. Similarly, composite builds are a game changer in terms of integration of multiple libraries, compared to the good old SNAPSHOTs (shameless plug, I wrote a plugin which lets you easily use this in a multi-repository context.

In terms of dependency management, Gradle is also years ahead what Maven provides (dependency constraints, dependency verification, rich version contraints, module substitutions, variant aware resolution…) in order to solve real world problems, but also support more complex ecosystems like Android or Kotlin MPP.

One more illustration where Gradle can be better is for plugin authors. As mentioned by Andy, as a plugin author, Gradle makes our lives significantly easier, since it doesn’t have the limitations of the Maven lifecycle. For complex topics like native builds, which require things which are significanly off “The Way”, for example because we need to run tests in JVM mode, then run a native build, then run the tests in native mode with the output of the previous test, etc… the Gradle model is significantly more suited to this and doesn’t force us, plugin authors, to write convoluted code reaching Maven’s internals (like invoking mojos by hand, something users cannot do in general) to be able to do the job. This is just easier.

I know there will be a lot of resistance to change, but Gradle, IMHO, is the future. I also will never say that the learning curve is flat: it’s not, especially for folks who have dived into Maven for years: Gradle works fundamentally different, but once you are used to it, it’s hard to get back. Sure, you will find people rolling back from Gradle to Maven, that’s inevitable.

Long story short: you will find people saying that Maven is better than Gradle. If you do, please define “better”, because I can objectively find many areas where Gradle is better. I can personally find areas where Maven is “better”. For example, it’s easier for Maven to pass properties to override some properties of the build. However, this often relates to a “wrong mindset” in how you should design Gradle builds (for example, folks used to using Maven profiles, when they are totally unnecessary with Gradle). Or, the stability of the Maven API for plugin authors, compared to Gradle which is moving fast and breaking things once every year (for every major release). This is a pain point for plugin authors, but not for users, who generally never suffer from this.

I won’t go on because there are many reasons to prefer Gradle over Maven. In the end, you still have the choice to stay on Maven, I won’t blame you, but give Gradle a try 😉