Gradle or Maven? I really don’t care
This kind of shocked me at first. I’ve been hearing that gradle is hip and cool and maven is old and stagnant. All hail gradle!
And yet, in just a few hours, I realized that I really didn’t care. I didn’t care because both gradle and maven are GREAT build tools. That automate the entire process. Since 99% of my time spent on a given project is in the source code and support scripts and NOT the build process, I don’t really care a lot about what build tool is in use.
I understand people run into issues with maven. If you try to deviate too much from the convention you will pay for it dearly. Guess what; it’s not that hard to follow the convention. It’s not a bad price to pay for being able to jump to other projects and see the same layout. It’s also handy that IntelliJ IDEA can easily suck in a multi-module, maven-based project without batting an eyelash.
What about gradle? It’s pretty neat as well. I sure enjoy updating the build system when needed without having to bear all the XML cognitive overload. Gradle’s groovy-based system is simpler to read. I appreciate that IntelliJ IDEA can also crack open a gradle-based app just as well.
But then again, it can run away. I’ve seen REALLY complex build systems (like the Spring Framework). It becomes an art to discern all the stuff involved to build that hunk of software. Why? Because Spring has a lot of stuff going on! No build system can make it super simple.
Pros and cons for each?
- Gradle it easier to read. No XML overload. It’s easy to use, declarative, and comes with gobs of plugins. I have even had people tell me that crafting your own plugin is pretty easy. But it doesn’t have the concept of parent projects that can provide inheritable version numbers
- Maven is widely adopted. Even when we wanted to primarily use gradle for Spring’s Getting Started Guides, we decided that maven support could not be ignored. Maven has more than one way to inherit a set of dependencies and properties. This feature is REALLY useful. Spring Boot leverages it widely, effectively declaring a stack of dependencies it uses.
Bottom line: either one of these are better than some ivy+ant solution. I have worked with ant in the past. It is so customizable, so detail oriented, so extensible, that you can ONLY interact with it at the low level. I don’t imagine IntelliJ IDEA being able to suck in an ant project and immediately fetch all it’s dependencies.
You are dragged down to that horrendous level of detail every time you want to dig into an ant-based build. Most of the time, when I interact with the build system, it’s because I need to roll some versions and upgrade things. Maybe add a new module. That’s easy.
In the end, trading in such detailed complexity has a huge productivity payoff. I have to use both because of the proliferation of projects, hence, it’s not a steep job for me to switch gears.