A functional Journey

by Rewati Raman
HTML5 Icon

When to use Maven not Gradle

08 Jun 2017

I don't like Maven much. I have been involved in various debate about why maven is not so much fun. But when I started learning Scala I started missing Maven (For first two or three weeks till I decided to learn SBT internals). Now I love SBT. Then I recently got introduced to Gradle and again loved it over Maven but not more than SBT as Groovy is not my strong programming language. I don't mean to compare gradle or sbt they both work great and have very advanced features compare to maven. Still I feel there are very clear moments when you should stick to maven rather than sbt or gradle.
I have used ant,maven,sbt,gradle and very little bit of rake too. And I feel none of them is a silver bullet, they all are bad at something (whether new or old). Now scope of this article is to justify when to choose maven over gradle. So with that being said here are the criteria for deciding the circumstances for choosing maven over gradle.

When things are too simple to be complex

Mostly build files are small lists of dependencies, properties, settings and may be little more. Now if you are writing simple java project, which is true in most cases, you will have a very simple small lists of dependencies. For these kind of projects a Maven POM file will look almost exactly the same as a gradle file. I know xml sucks, but just to get rid of xml you should not introduce a non natural syntax in your code. Gradle is heavily dependent on Maven. Gradle has a Maven plugin, uses the Maven distributed artifact network, etc. I totally fail to see why would we need gradle in a simple project to do identical build configuration like maven.

When consistency and simplicity is the factor

Gradle philosophy of being flexible in configuration makes it highly unstructured and non standard build code. Gradle build files are mini programs. It doesn't have a structured model like pom file. So it will change from developer to developer, just like sbt build files and we all know how hard it can be sometimes to read sbt build files. Now if someone other than author have to read gradle build file, then he or she will have to first read and understand it like a program. The mental resources required for this are significantly greater than what is needed to understand a configuration file. Whereas Maven pom file always will be written in same way. You can just pick any project and read pom file and they will be exactly the same way. Nearly all POM files you encounter will look the same and will be easily comprehensible. Even a non java programmer can read a pom file and understand what's going on. This may not be the case in gradle file. I have almost never seen a POM file that I can't understand. I've encountered many Gradle files that are spaghetti code.

When code base has 0% of Groovy

Gradle build files are written in Groovy based DSL. Most commonly java project have to support xml so you are not adding any extra weight when you use pom files. But if you use gradle you do add one more language to your project, with no extra benefit. Now this can be a totally different case if the project is an android based project or your build steps involve some crazy instructions. But if the project is not an android based project and it is a simple java project, then adding this new language doesn't make it a functional approach. This will also makes life hard for non Groovy base team to debug a very rare bugs. If your team doesn't know a language it's not a good idea to introduce it into your infrastructure.

When gradle preachers are not Groovy experts

Gradle is a advanced build tool compare to maven. But most of the non groovy gradle preachers are minimal user of gradle. Means they use only the basic features or configurations of gradle. Most of codes are googled and copy paste or hit and trial codes. Now this approach may work perfect with small and simple projects in a non groovy team, but if the build process gets complicated then it will be hard for team to fix it, as the only expert in gradle in their team doesn't know the language gradle speaks. Without having capability to write and handle advanced gradle features, it makes no sense to use it over maven. And don't forget that gradle user is assumed to be aware of maven.

When devops are your friends

In my past experience in software development, I have seen the most complicated parts of build files, weather its ant, sbt, maven or gradle build files, are the parts that involve deployment or package delivery or integration testing or CI configurations. These all area are devops responsibility. Once code is out of development cycle then devops may have to deal with build files to customize it according to the needed infrastructure requirements. Now maven and xml are universally known to all devops, but it maynot be the same for gradle and groovy. In my past companies I have seen when devops can not integrate their build script with developers build system then situation can get really frustrating. This may lead to poor deployment and delivery process or arrangement, where both the party may end up blaming each other. All developers should write build system in such a way that transfer or ownership is easy. So if you don't have gradle friendly organization and probably sticking to maven will be more sane than gradle.

When you are seeking standard and better support

Gradle ide support have improved but still inferior to Maven support. Maven is the standard for Apache OSS projects and most non-Apache OSS projects. Allmost all opensource project prefered how to tutorials are maven based examples. In this analysis from October 14, 2014 shows more than 65% users of eclipse and IntelliJ are maven user, and about 20% of intellij users and about 5% of eclipse user are gradle users.

Conclusion

Applying functional thinking while making decision then, when given that I have a non groovy team and non gradle friendly devops and have 0% groovy in my code base and with very basic build configuration I will not choose gradle over maven. Here the decision has very less to do with what gradle can do or cannot do.