I suspect that Android and Kotlin have really helped Gradle adoption. But even before this, Gradle has a very easy "customize it" approach. Though... honestly,

I suspect that Android and Kotlin have really helped Gradle adoption. But even before this, Gradle has a very easy "customize it" approach. Though... honestly, it might just be that people hate XML. Personally, I've stuck with Gradle, even though I'm not really happy with it, mostly because of these features: 1. Composite builds - https://docs.gradle.org/current/userguide/composite_builds.html https://docs.gradle.org/current/userguide/composite_builds.h... 2. Dependency substitution 3. "local" plugins, i.e., stuff in `./buildSrc` These features let me combine projects defined in multiple git repositories in a "workspace" project. Then IntelliJ can read all these projects, and it magically substitutes my local version over a specific version. Ergo, I can have multiple libraries, edit and debug them and and application code. When it's time to commit, I push them up in individual MRs back in GitLab - And I could swear GitLab was going to make some kind of multi-project MR possible at some point. So, the "workspace" is generally for development, then we use GitLab CI for each project independently, for a "formal" versioned approach. It's quite nice. In any case, I'll typically work with a pretty broad set of apps and libraries in a single workspace, typically between 15-30, and Gradle and IntelliJ handle this just fine. Our Maven projects with fewer modules never seem to get things working as smoothly ironed out - I suspect it's something wacky going on with the build. So, while Maven allows build composition, but doesn't really have the dependency substitution concept, useful for local workflows. Also, it just doesn't seem to perform as well, especially with the IDEs we've been using. I can't explain it, haven't investigated it, but then again, I've found a solution that works.