Switch the default project type to Gradle

[wilkinsona]

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 ;)

[wilkinsona]

For anyone who'd like to always override the default build system (or any other setting) to suit their personal preferences, I've just added an explanation of how to do so to the opening comment.

[MartinKanters]

I'm not going to go into whether Maven or Gradle is better. I have my preferences for Maven, but I'm biased, just like @melix probably is, as we have both worked on either tools.

I do think that Maven is more beginner-friendly, and I have concerns that the beginners starting out with Spring without any prior JVM knowledge will potentially have to deal with build tooling complexities. I hope this will not scare them off.
Then again I'm not sure who the main target users of spring.start.io are.

And I just wanted to mention that, while @melix made an impressive post, Maven is working on a lot of the nice things that Gradle has brought to the JVM ecosystem. Most of them are already available for use. The Maven Daemon, Wrapper and build cache extension for example. Also changes to the Maven reactor coming in Maven 4 will indeed make it less needed to use "clean" and "install" (if there are cases left, please provide a ticket on the backlog). Currently the first alpha of version 4 is being released.

[delanym]

@melix mentioned a whole bunch of ways Gradle is light years ahead of Maven, but none of these things, as far as I can see, could not be implemented in Maven. Sure, things are slow in Maven's open source world compared with Gradle's, but its not quite the tragedy-of-the-commons that is Jenkins.

The heart of the difference is not the maturity of their features, its how they present their configuration: as declarative configuration, i.e. as data, or as imperative statements. With hypertext its easy to infer what's going on and make modifications. With a DSL you're forced to learn the types (and if you're not familiar with Groovy/Kotlin, the syntax too).

Gradles know what an important difference this is and tried to introduce a declarative syntax, but that failed. By the time I learnt how Gradle worked I was over caring and went back to Maven. I don't work at CERN. If build performance is your criteria for "better", Gradle is currently in the lead. If you've got a new face in the office every week and you go to bed worrying about what will happen to the system when you leave, its probably ease of inference, and Maven will ALWAYS be ahead.

Anyway, competition is healthy. I don't see either one burying the other.

[michael-o]

Gradle is being done by paid developers, Maven is being done by volunteers. This makes a HUGE difference.

[rmannibucau]

Just my 2 cts but maven being a descriptor it has almost never any issue in any editor/ide to load its model and dependencies but gradle being a script has a lot of potential pitfalls (even in idea where it often does not work the first time) so can be neat to stay on the main default and smoother OOTB for most dev build system?

[melix]

This is a ridiculous statement. First Gradle (the build tool) is free of charge and OSS software. Second Gradle Inc (the company) makes most of its money out of... Maven: Develocity (their only paid product) supports different build tools, and the most widely used is Maven. So following your argument they have an incentive on making Maven complex and intricate.