Opinions on Gradle

I have used maven and ant for a couple of years and last year, I tried out gradle. I have a generally favorable opinion on gradle. Once we got it setup, it stayed in the background and we seldom had to fight with it to get things done. That said, there are a lot of rough edges especially around IDE support that needs to be sorted out. We start out with a bit of context and then go on to enumerate our encounters with gradle.

Nature of the build system

The build system was of medium complexity. We were depending on third party systems and the build system needed to ensure that those components are running before starting the application. Though in retrospect, we should have separated out the development and the deployment environments and should have used tools like vagrant to manage the deployment environment, gradle worked just fine in our context.

Things that gradle Enabled

  1. Enables you to have very customizable assembly and packaging. Try creating a war and jar for the same module in maven.

  2. Though fundamentally based on tasks(ant), gradle has maven like plugin support. Additionally, unlike maven, you can modify the properties of the tasks that the plugin exposes (like adding an additional dependency).

  3. Very good support for multi-module projects. Projects can refer to tasks in other projects, add them as dependencies etc.

  4. The support for custom assembly and packaging is further supported by the configurations framework for dependencies. This gives you great control to specify which artifacts depend upon which libraries.

  5. Ability to write Java code is a big win

  6. Gradle wrapper is a big win. It helps you avoid the hassle of “installing” gradle on your build boxes.

  7. Our experience with gradle followed the power law: 80% of our effort was spent on setting up the basic framework and only 20% overtime to do some customization. This was not the case with maven when you had to spend a disproportionately large amount of time to do trivial things that did not fit well with the maven’s framework.


  1. Though the ability to write Java code is a win, you would expect gradle to provide you with good language level abstraction over process builder for which Java code was primarily used (our application was packaged as a runnable war with its own embedded server)

  2. Having to learn a programming paradigm just for a build tool might be an overkill for some (you would have to have a solid understanding of lambdas as gradle relies on them heavily)

  3. Gradle tries to be too clever with caching of artifacts which sometimes leads to hard to track bugs.

  4. IntelliJ support is still not that seamless (I have categorically specified only IntelliJ as I don’t see myself moving to eclipse anytime soon even if it has fantastic support for the tool)

  5. The documentation is not world class, you would have to go through a lot of pages to find the one property that you could set on a task that will enable you to do something; Though this gets pretty rare overtime)
  6. How the groovy structures map to Java classes is not immediately apparent. This is compounded by the fact that the documentation frequently refers to the Java side of the model which is a pain when getting started with gradle.


When you have people who have played with gradle around,  you should definitely give it a shot. It is exciting, powerful and lots of fun. It removes rigidity without sacrificing too much on comprehensibility of the build system. I am really happy to have used gradle.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s