From the Maven to the Gradle
I have been itching to try out the Maven alternative Gradle for some time. I am not really in the crowd of maven haters that seems to have formed lately, but I am always interested in making my builds better.
Maven
Maven has done a great job of popularizing the idea of convention over configuration in builds. It was the kind of shift I had with Intellij IDEA. Martin Fowler referred to Idea, “as the inflection point of IDEs” (Fowler). The IDE world had been reshaped. Every IDE that came out after Idea was born in a world that expected more. I feel this way to a lesser extent about Maven. Maven changed the game.
Maven introduced the concept of a binary repository not as an option, but as a fundamental part of the build experience. Maven expected the project to be laid out in specific way. When it was laid out the “Maven” way, the project got a lot of functionality for free: compile, test, reports, etc. Of course, it was rarely this easy. Often projects would require customization. This was especially true of existing projects which were not as easy to mold into the standard layout. To make matters worse, heavy-lifting scripting needed to be written in an abomination of a language called Jelly.
Time has passed and Maven has matured. It now includes a much better mechanism for handling scripting with Java and Groovy plug-ins. Projects have been created from the ground up in the Maven ecosystem. A wealth of plug-ins have been created. In many ways Maven has become the de facto Java build tool. Why would you use anything else?
Why Grails?
Of course this begs the question, why would I want to investigate Gradle? I suppose it is partly bandwagon jumping. The Gradle wagon seems to be cropping up more and more as of late. Perhaps this is just due to numerous mentions at the [No Fluff Just Stuff](http://www. nofluffjuststuff.com/) travelling road show. Or it could even be just my old friend Groovy and I getting reaquanted.
The truth of the matter is that Maven does have warts: XML, bad composition model, verbose plugins, and neophite unfriendly to name a few. Maven is in heavy use and moves slowly (this is a good thing in a tool with huge dependencies). Unfortunately, this leaves an opening for a lighter younger tool. It feels a bit like the process all companies go through as the grow. At first, they are the young pretender trying to fix the world. Then, they are the established solution. Finally, they are the tired old guard riding momentum and market share.
A Comparative Example
Before I start down the path to Gradledom, it seems prudent to provide an illustrative example of the difference between the tools. Below are the base build file for both a Maven project and a Grails project. I am trying to be the exact same for the sake of comparison. Each file would compile and build a basic java jar with only a test dependency on JUnit.
Simple Maven Project (pom.xml)
http://maven.apache.org/xsd/maven-4.0.0.xsd
"> 4.0.0 com.mycompany.app my-app jar 1.0-SNAPSHOT Maven Quick Start Archetype http://maven.apache.org junit junit 4.8.2 test Simple Gradle Project (build.gradle)
apply plugin: 'java'

repositories { 
    mavenCentral() 
}

dependencies { 
    testCompile group: 'junit', name: 'junit', version: '4.8.2' 
}
Conclusion
I don’t think this comparison is really fair. Maven brings a lot to the table with just that small XML snippet and the flexibility of Gradle is not well represented in the build file. It does illustrate a clearly different approach between the two projects. So from here, it is time to get my hands dirty…

Comments

Popular posts from this blog

Bigger than the cloud?

3 problems with quality code

Programming and kids (or how I learned to love code)