Over a million developers have joined DZone.

Thinking in Gradle!

DZone's Guide to

Thinking in Gradle!

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

Since my first encounter with Gradle and Hans Dockter (TSSJS 2009 in Las Vegas), I slowly (but surely) started to use this new build tool in many environment and projects.
Today, I’m hooked and I don’t think there is a better way to build!
But, the main issue I encountered is how to convince other that Gradle is the good way to go? It took me time to get the hang of it, it took even more time to understand what Hans meant when he says: “What’s important is the model!”.

Here is how I describe my “Thinking in Gradle!”

After many years of Ant, and Maven brain washing, the main paradigm shift that I needed to understand the power of Gradle is: Gradle let you write code that create a dynamic model of your build.
I needed to stop thinking in terms of declaring properties (Ant), or POM static model, but an aggregation of executable blocks (Groovy closures), that will create the exact model of what are my projects, task, dependencies and products.
I don’t need to “extends”, I don’t need to “exclude”, I don’t need to “override”.
When playing with static declaration of your build model, the way to avoid repeating yourself is by declaring what’s good for 80% of your modules in a super POM, and then adding skip or repeating detailed plugin configuration for the other 20%.
In any case, you are repeating yourself a lot, and you always try to change your code or module layout to fit the less resistance of your build tool.

Your “static” build model is freezing your ability to re-organize your modules as they should be.

With Gradle, the build model is created from executable Groovy code. So, nothing, I really mean nothing is static.
It’s extremely disturbing for newcomers. I want my properties, my XML, my declarations :)
No! It’s only code, dynamic Groovy code!
The model will emerge from Groovy collection closures (apply this to any model element that matches), some “if”s when needed, and a lot of beautiful GStrings for expressing dynamic values. You cannot keep your thinking of static XML, when you write your Gradle build!

OK, you may think that the dynamic part is just your mental representation of a POM hierarchy and dependencies.
Well, in Gradle the execution task graph (every little plugin execution of your Maven lifecycle, which is extremely static and a nightmare to modify) is also dynamic.
It means that the way you chain the tasks that will be executed are also defined in code, not in XML :)

And of course, the part that everyone expects: The execution block of a task is also in Groovy (or Java) code.

Until I let go of my old concepts of static task dependencies (Ant), and static project model (Maven), I missed most of the beauty and power of Gradle!
Hope this will help others. 

From http://blogs.jfrog.org/2011/05/thinking-in-gradle.html

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}