Last week, Luke Daly arrived in Portland to teach a three day Gradle class; the folks at Gradleware were nice enough let me audit the class (so it only cost me a couple of thousand dollars of lost billing revenue to attend). My goals for the class was to gain a deeper understanding of how Gradle works, so that I could write more efficient builds, diagnose problems, and write my own plugins. The class scored very high on all of those counts!
Much of the first day was spent on basics, including a very useful introduction to the Groovy programming language (which is the basis of the Gradle DSL). Even though I have used Groovy pretty extensively for testing purposes over the last couple of years, there were features I've glossed over in the past that turned out to be very useful.
The class is taught largely bottom up: from the basics of declaring tasks, then actions on tasks, and gradually working up towards defining tasks inputs and outputs. Compiling Java came pretty late, which seems curious since that's the primary job of Gradle, but this makes sense from a bottom-up approach as SourceSets can then be described correctly.
The class alternates between lecture and discussion, and short focused labs. At the end of the third day, we worked on tuning up our own builds, passing the video projector cable around ... we had a good time making the Tapestry build more efficient and readable, as well as adding new features to it.
I'm feeling very good about my Gradle skills after attending the course; I've already been able to make further improvements to the Tapestry build subsequently, and I have plans for more involving things going forward.
The return on investment for this class is a bit tricky; Gradle simply does so much straight out of the box, and even without a strong understanding of its structure, you can kind of get it to do what you want just by guesswork and Googling. If you've been using Gradle for a while, I give this a cautious recommendation: getting back the three days of invested time may take a while to pay off. On the other hand, if you are currently dependent on Ant or Maven ... sign up for the next class and get yourself switched over, today!
2 comments:
Greetings Howard,
What would you present as a compelling reason to switch from Maven to Gradle?
You seem to have worked quite a lot to do the build migration for Tapestry so at the end of the day, what do you feel you have really gained versus keeping the status quo?
Respectfully
I've gained a lot.
I've gained the ability to easily add new modules to Tapestry, in just a couple of lines of code.
I've gained the ability to easily extend my build; for instance, adding CoffeeScript compilation to the build.
I no longer have the feeling of dread about the build suddenly stopping working, something I've repeatedly experienced with Maven.
I can describe my dependencies more concisely; I can control where those dependencies come from more easily. I can control how often Gradle searches for updates to (snapshot) dependencies.
Mostly, there's a sense of openness; I own the build again, not the vast, invisible layers of Maven plugins and modules.
Post a Comment