I guess it makes sense to have your own build tool written in the language when you do not want to depend on the JVM (scala-native, for example). Then you don't have to hope maven/ant have their own native implementation.

As a plus you get to write your own DSL which might be more acceptable by the language user than that of another language or XML. Of course you might also invent a bad DSL; it's no easy task.

Your build tool being built on the JVM doesn't preclude it from building non-JVM targets. See for example bazel, buck, and pants building a bunch of different languages.

It solves scala specific problems. Incremental compilation, long startup versus hot background daemon....

Plenty of people do use maven, but there's a lot of power in being the assumed popular option, which sbt is.

Maven is no longer maintained, and has many long-standing bugs that may never get fixed.

This mirrored repo https://github.com/apache/maven says that the last commit was five days ago. So would not say that is no longer maintained.

I wouldn't go so far as rbt to say that it's unmaintained, but the development attitude is that of maintenance (features like Java 9 modules compatibility) rather than active development. Gradle has improved by leaps and bounds very quickly; the Gradle build daemon makes build tasks feel much quicker and powerful in day-to-day practice, and is clearly now the preferred tool for new projects.

I only use Gradle on Android projects, because we are forced to by Google.

Everywhere else all our Java projects are Maven based and there are no plans to change it.

Look, if you have a lot of pre-existing Maven builds then of course the story gets more complicated. Large enterprises usually have higher priorities than spending large $X on any kind of migration that's not absolutely necessary, including the costs for retraining dozens or hundreds or thousands of developers to use a new build tool and to overhaul tooling that was built on top of the old solution (e.g. deployment scripts invoking mvn deploy and Maven reports), and can often result in choosing options that are technically worse but organizationally better.

What I mean is when you have the freedom to choose a new technology stack because it's a new project - because a lot of companies still won't give you that freedom even with new projects.

Unless you have some objection against Gradle itself?

Surely.

Maven doesn't require 2 GB, a SSD, a background daemon and different dependency commands to be fast.

Also Maven has never been four years in a row subject of build performance at multiple conferences.

For those that don't suffer from XML allergy, Maven is quite alright, IDEs can provide completions that actually make sense and nice graphical tooling for dependency management.

Maybe you meant to say the maven scalac plugin?

What? I thought it was _the_ java build tool...

It is. It doesn't even need to be updated that often as most of the functionality is in plugins. A large set of which are maintained by the core development team.

It is.

Gradle only became hip after Google forcing it upon Android developers.