Thinking in Gradle!

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 meannothing 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.

Conclusion
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.