JFrog Ltd founder in 2008, and AlphaCSP founder in 1998 as chief architect. My development experience goes back to 1992, and I'm hooked on Java since 1997. My Open Source activity are with jfrog and setllarium4Java. Frederic is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Thinking in Gradle!

05.24.2011
| 4085 views |
  • submit to reddit

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.

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. 

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

Published at DZone with permission of Frederic Simon, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Kathy John replied on Tue, 2012/02/21 - 1:32pm

Very helpful article, thank you. I just started playing with gradle after having attended Ken Sipe's demo at the New York Java User Group. You're absolutely right that you need to let go of the things you learned when using ANT or Maven. Gradle is a DSL for build, which opens enormous flexibility - but it takes a while to understand what that means.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.