It depends what you are doing on the jvm. Java is pretty well supported with both gradle and maven. But a lot of stuff just defaults to gradle these days. I'm d

It depends what you are doing on the jvm. Java is pretty well supported with both gradle and maven. But a lot of stuff just defaults to gradle these days. I'm doing Kotlin (server side and some multiplatform stuff; no android). With Kotlin, Gradle is the only good option. Anything else just doesn't enjoy first class support from Jetbrains. They don't document it. They don't support you. You can probably make maven do most of what you need for simple Kotlin projects. If it doesn't work, you are on your own. Not worth the trouble. And the kotlin script dialect for Gradle is actually making things nicer gradually (IDE support for that is way better). What Maven and Gradle have in common is that they are quite convoluted and complicated tools for what they do. I have a love-hate relationship with both as they can be serious time sinks when they don't work as advertised. But I'm also smart enough to know that I need to use one of them as the alternatives are usually worse. I've been on projects where people tried to make maven do things it clearly wasn't good at. I learned a hard rule there: never replace a 5 line bash script with an unreadable 300 line blob of maven xml depending on all sorts of exotic plugins. It will break on you. Repeatedly. And it's going to be a PITA every time. That five line bash script is looking really tempting when you've banged your head against the wall in frustration for a few hours. Same with Gradle. Both tools have things they do well, things they can technically do that are a bit of an afterthought, and things they just really suck at. And you usually end up with a mix of all of those things. Having said that, doing custom things with gradle tends to be a whole lot easier. You can basically just do whatever with files and directories in some custom task. I've not used Ant in about 15-20 years or so. Used to be quite OK as an option when the Java world was a lot simpler. But I've also dealt with some really hacky & convoluted build scripts back then. A good practice with any build tool is to maintain and nurture your build files and update tools and dependencies regularly. I've been on projects where people just stopped caring and and fixing those projects is usually a chunk of work. It's a form of technical debt that you should probably avoid. Once you can't upgrade because all hell breaks loose when you do, it's too late. What I like with gradle is that it has the gradle wrapper. Maven has a wrapper as well these days. So you can control which version of your tool of choice builds your project and developers don't have to worry about installing the right version. Every few months, I just update my projects to require the latest gradle version and fix whatever needs fixing. Doing this incrementally is pretty straightforward. If you wait five years, good luck. Maven is a lot easier with this because effectively it barely changes for the last decade plus. And not because there's nothing left to improve. There just isn't a whole lot happening in terms of new stuff in the maven world. Maven still is on the same major version since I last used it; a decade ago. And there haven't been a lot of minor version bumps either. Another thing I use is the refreshVersions plugin for Gradle (mentioned in the article). I highly recommend taking a look at that because it's great and really easy to take into use. It makes keeping your dependencies up to date really easy. Out of date dependencies are another form of technical debt. So you don't want all the security, stability, correctness, and other fixes? Or is it just that you can't be bothered to find out if there are any? If the answer is the latter, you probably have a pile of technical debt right there. The longer you delay updating, the harder it gets. BTW. that's portable advice to just about any language and build tool.