It's no mystery that I'm a big Gradle fan ... it's by far the best build tool I've even seen. Build scripts are concise and readable, and Gradle the easiest build tool to configure and extend, as well.
I fought an uphill battle with the other Tapestry developers to replace Maven with Gradle. Yes, we had an existing Maven build and it worked (most of the time, until it didn't). Now past the switchover, we're really reaping the benefits: faster builds, fewer headaches, and it's much easier to add new sub-modules. Despite the achievements I've made with Gradle, there's a lot about this powerful tool I still need to learn. So I was surprised and pleased when Tim Berglund contacted me to help find a venue in Portland, Oregon for Gradle training.
They're now advertising that the three-day training is coming January 17-19, 2012; details here.
I've seen Tim speak at a number of No Fluff Just Stuff and Uberconf sessions; he's very good. If you are frustrated using Ant or Maven, you need to learn Gradle, and I can't see how getting an intensive brain dump won't do anything but save you time and money.
3 comments:
I love and hate Maven at the same time - the concepts are good, but the execution sucks.
I miss the profile support, the property mechanism, the various plugins and the convention-over-configuration approach in other systems.
Do you know of a good resource that compares the two?
I see Gradle as a super-set of the functionality promised by Maven without it's significant warts and frustrations. Gradle has its own warts and frustrations, but they are 1 or 2 orders of magnitude less significant.
You get a sense from the Gradle team that they eat their own dogfood and care about their users. From the Maven community, any criticism is met with "you just don't get it" or "just read the book".
What's frustrating most about Maven is the fact that they don't practice what they preach ... for all that Maven is supposed to create project documentation, the majority of Maven plugin sites are out-of-date, do not indicate version numbers, and are not linked properly to each other. Quite often I've had to download a plugin, guess the version number, and read a lot of source to figure out what I want to do ... and that source is pretty terrible: the few actual comments died of loneliness years ago, much of it appears to be machine generated (from various XML files), and there's lots of collections with neither generic types nor documentation for what types of objects the collection contain. Gnashing of teeth ensue.
Gradle has its own problems: the behavior is dictated often by the interaction of the DSL, particular Java and Groovy implementation classes, and Groovy extensions to those classes ... it can be hard to figure out how things fit together. However, I've seen, over the last year, at least some progress on that front.
Certainly, Gradle has done well by doing a bit less, but doing it quite well. Maven has always had a "we can solve every problem" mindset that tended to fall apart in practice, as plugins for anything non-trivial always were cranky, or organizationally specific without reasonable ways to extend or override behavior.
Just checked out Gradle again (its been some time since I first looked at it), and I must say I like what I see.
If changing the build system and maybe even moving to the Maven/Gradle directory layout conventions wasn't such a huge pain in the ass... I hate being the "build guy", I got enough to do as it is.
Post a Comment