Thinking in Gradle!
Join the DZone community and get the full member experience.
Join For FreeSince 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.
Opinions expressed by DZone contributors are their own.
Comments