Archive for March 2013

Gradle over Maven for Groovy/Java projects

* "The Ant" problems

For many years, I've been down with Maven and I still am. In many projects, I've seen some gigantic Ant scripts. Ant has often been a maintenance nightmare in huge applications, fix a script and notice that your eyes are bleeding.

As "most"corporate developers don't use Ivy to resolve dependencies with Ant, you typically end up with 3 scenarios:

  • The dependencies are stored in the version control server, that can get people fired at few places.
  • There's some kind of repository concept with jars at dedicated locations (Windows shares, NFS, etc.). The dependency resolution involves tons of scripting or some Ant tasks.
  • Dependencies are stored at a secret location(mapped drive to a Windows share that you'll know about one day) and you can only build after lots of configurations.

Some of the good things about Ant are flexibility, accessibility, documentation. Most developers know how to use Ant and writing custom tasks is not usually hard.


My initial Master thesis subject was supposed to be about Apache Maven, but I bailed out... If I recall correctly Maven had only beta releases at that time with very little documentation.

After downloading Maven binaries, I didn't know what to do and how to use it: close to zero documentation and not really "accessible". When I was about to finish my MBA, I decided to give it another shot. It felt like "I looked at Maven and I got scared...".

The Jelly Issue

While many people didn't like Jelly, it provided some basic scripting capabilities inside the build file. If I recall correctly plugins also needed some Jelly files and many developers were annoyed by that constraint.

Sometime ago, I wrote an automation tool with Commons Jelly to setup Web hosting on Tomcat.
The tool was a launcher with few relatively small Jelly scripts to perform the following:

  • Read the list of users from an excel spreadsheet or XML file 
  • Setup FTP accounts 
  • Modify the Tomcat XML files to create application context paths for Web applications 
  • Populate the user information in a database(credentials, ftp and tomcat information)
  • Send email notifications with the account details.

Understanding Jelly made my life easier with Maven until it reached 2.x and Jelly was dropped at that time, if I recall correctly.

Maven evolution

With Maven 2.x things got cleaner and more stable, documentation got better and so on. Still many companies didn't give Maven a second chance. Then came Maven 3 and things haven't changed that much at the corporate level.

Most Java development companies still use Ant and few of them use Ivy to resolve dependencies. I do see Maven here and there, time to time, but not that often.

Maven adoption

From my experience, Maven has always been an issue in non Open-Source projects: too complicated, not worth the effort, too much impact on the typical IDE or build/release workflows.

While convention over configuration introduces a potential "lack of control" or flexibility, it also have its pros.

Gradle to the rescue

In the past, I've not really been a big fan of any kind of dynamic or scripting language, unless it's used for scripting or as an extension module. I would probably never have considered Gradle and similar tools in the past, because it would have made me feel "uncomfortable".

Nowadays, I'm willing to take advantage of Groovy, Jython, Clojure or whatever.

If I were doing some Clojure, I would try cake or lein as build tool, unless there's a feature that I need that is only available in Maven. Why? For just 3 main reasons :
- A tool dedicated to a programming language, often means more power and integration.
- There are not many attempts to do too many things or to be too generic, things are easier.
- Having scriptable builds and zero XML is cool.

Accessible to Java Developers

While a Groovy DSL to write a build script is no XML or Java, it's more expressive.
Learning some basic Groovy concepts is easy for Java developers.

Solid documentation

I was impressed when I saw the Gradle manual. It's very good and it's easy to read and understand.

Readable files

Last year, after migrating few personal projects from Maven to Gradle, I felt relieved. I didn't have some crazy POM files, but still too much XML to write (or copy/paste).
The Gradle build files were easier to read/understand with less lines of code.


Adding custom tasks with Groovy Code, without writing plugins unless you need too, this is really nice. If you need plugins there are couple of them out there.

While there are not as many plugins for Gradle as for Maven, I believe that Gradle is getting more  momentum. Many projects such as Hibernate already switched from Maven to Gradle.

Posted in , , , | Leave a comment

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by