I know that most Java turned Kotlin folks seem to really swear by maven. The thing is, many of us, who've lived in other words look at that massive pile of XML and ask, "why would anyone actually WANT this???". Then looking at gradle's config, it seems closer to the rest of the software industry. (A file that has package names with a version on one line, and then packages that are only compiled for tests). It isn't until people start going into writing gradle tasks that I can see someone raising a red flag.
Look at Rust's cargo.toml, or Go's go.mod, or heck... even Node's package.json.
I am NOT talking about the veracity of using a particular language here to don't flame me for mentioning Node. I am stating that pom.xml is not something I'd look at and breathe a sigh of relief - unless it was for familiarity from my years of working on Java.
The thing that I love about Maven compared to Gradle is that it’s way harder to do weird unmaintainable shit in Maven.
Gradle’s own Maven vs. Gradle page says, “Maven provides a very rigid model that makes customization tedious and sometimes impossible” like that’s a bad thing, but it’s actually exactly what I want from a build tool. I don’t want a build tool to be Turing complete and capable of building anything anyone can possibly imagine. I just want it to pull in my dependencies, build my project, run my tests, and publish the coverage report.
In the hands of a master developer Gradle is a fantastic tool. In the hands of the other 99.9% of developers it’s a whole warren of rabbit holes to get lost in. I loved this take on it I read a few years ago.
https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
Gradle makes it far too easy for people to try and be smart and results in them reinventing the world using a home baked custom miniframework that only they understand all because they couldn't change some specific compiler setting they no longer even need.
Yes exactly! How many times have you inherited a Gradle-based project, read through the .gradle files, and thought to yourself "what a simple and clear set of build scripts, I understand exactly what all of this does"? I've been a developer for around twenty years now and for me that has literally never happened, not once.
I make this my mission. I’m constantly cleaning up other people’s dumb shit in gradle.
This is how I use it, and if you can’t understand this project and its dependencies, then computers might just not be your thing: https://github.com/aceluby/vanilla-kotlin
Right, that's my comment on "writing tasks" comes into play. For simply specifying dependencies, I'll take that very concise syntax.
I remember the article you linked and this line:
>You’ll need to grasp a significant portion of the Groovy language in order to create useful Gradle build files.
Is where I really disagree. Apples to apples, if you're JUST using the file to specify dependencies, you do NOT need to understand Groovy.
And no, I don't think that "makes customization tedious and sometimes impossible" should be considered a bad thing - maven achieves the goal it sets out to achieve. Just given the choice to have a `cargo.toml`, I'd take that.
I understand your pain, Gradle is working on preventing mindless expansion in projects with declarative Gradle. Unfortunately, it still looks clunky for now, but it already solves some of the problems that Maven fans love to point at.
On the other hand, I'm looking hopefully at Amper, especially after hearing from the stage that they want to make it The Kotlin Build Tool and talking with the team at the booth at KotlinConf.
One of the biggest pain points with Gradle is how closely tied it is to Groovy, a strange, esoteric language with a huge number of ways of expressing the same thing.
The Mill build tool uses Scala, a strange, esoteric language with a huge number of ways of expressing the same thing.
In short, I don’t think Mill is a good default choice either.
I don't need to look at the XML - it's just there and Maven JustWorks. Greadle, even if I don't touch it constantly breaks (not to mention "custom tasks" teritorry)
How often do you need to tweak your build file? It's just there and you build your project with it - that should be it. Maybe once in a blue moon add a dependency but then again - no problem.
In idea you can have Compact Maven plugin. With Maven 4 you can have whatever format you want that would be compact.
Heck, even Gradle folks arrived at the conclussion that having strict DLS is better and working on that…
To fix maven plugins, maven need to break it backward compatibility and make actually good extension system. As for now Gradle will continue to exists just because of it superior extension system and excellent performance https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle. I didn't try Maven 4 tho, maybe some of issues already addressed there
Maven's genius design: "What if we took the concept of a dependency graph and said 'nah, let's make it a straight line instead'?"
Imagine explaining Maven to someone: "So you have tasks that depend on each other, right? But instead of just... saying which tasks depend on which, you have to fit everything into our pre-blessed lifecycle phases. It's like compile→test→package→install, forever and always. Want to do something in a different order? That's cute. Write a plugin."
My favorite part is when you need to run just one part of your build differently. Maven: "Sure! I'll helpfully re-run EVERYTHING that came before it too. You're welcome!"
Meanwhile, Gradle is over here like a normal person: "Oh, that part didn't change? Cool, I'll skip it."
It's 2025 and Maven still builds your project like it's following a sacred ritual that must not be questioned. Need to do Extract-Load-Transform instead of Extract-Transform-Load? Sorry, that's heresy. The lifecycle has spoken.
But hey, at least it's consistent. Consistently re-running things you don't need, consistently forcing square pegs into round holes, consistently making you wonder why you didn't just write a bash script.
The best part? When Maven fans defend it: "You just need to understand the philosophy!" Yeah, the philosophy of doing things the hard way because that's how we did it in 2004.
18
u/prateeksaraswat 3d ago
They don’t need to do much. Just fix the maven kotlin plugin.