I've found myself using Groovy for all types of development issues and for different stages in the Java development lifecycle. In the area of builds, however, I've mostly stuck to using Groovy scripts within Ant build files or to using AntBuilder in Groovy scripts. In addition, I have wanted to expand my knowledge of the great Groovy ecosystem by working with products new to me such as GroovyFX, Griffon, and Gradle. With that in mind, I left the Hilton San Francisco for my only time during this last day (all four other sessions in the Hilton) to attend "Rocking the Gradle" (21881) in the Market Street conference room in Parc 55.
The presentation was decently attended, but far from full. This is a good thing because it made it easier to see the low screens. Ken Sipe (Gradleware CTO) began his presentation by asking who was using Ant, Maven, and Gradle. Over half of the respondents responded to Ant, probably about one-fourth to one-third responded to Maven, and a handful responded to Gradle. Sipe said that Ant (+Ivy) is used by control freaks who want to control all aspects of the build while Maven is used by those willing to go with standardized build conventions.
Sipe told the audience about a short book on Gradle that is available called Building and Testing with Gradle. I also noted that there is an online Gradle Cookbook and there are some Gradle Tutorials. Sipe noted that one of the mistakes people make when learning and first trying Gradle is to coerce examples they find into their own situation.
Sipe stated that Gradle is a DSL built upon Groovy that has the same Apache 2 license as Ant/Ivy and Maven. Sipe stated that "Gradle is declarative" and "specifies what" rather than the "how." Sipe stated that Gradle allows developers to create a model in the project. Sipe said that, "in the end," you probably should know Groovy if you're going to get into Gradle for the long-term. He pointed out, however, that there are many good Groovy-based tools coming out, so the implication is that learning Groovy is a good thing anyway. I agree.
Sipe showed several examples of how easy it is to begin using Gradle for simple dependency mapping. One of the powerful mechanisms he showed was use of Groovy closures to provide a conditional specification of a dependency using
dependsOn properties. Wow!
Another impressive Gradle example that Sipe showed was setting of version information in the Gradle script using a call to Java's Date for a timestamp. The easy integration of Java/Groovy made this concise and powerful and clearly showed an advantage of not needing to specify a "script" in XML. Sipe talked about Gradle's being plug-in based and showed some examples of this. One such example was using Jetty Plugin. Other plugins include the War Plugin and custom plug-ins.
Ken Sipe stated there is no better tool than Gradle for multi-project builds. He then went onto talking about integration with Ant and Maven. Gradle implements with Maven repositories and there is "early work" on using Maven POMs directly rather than having Gradle-specific POMs. Gradle has really tight integration with Ant. You can reference any Ant task with ant.
Sipe said that using standard plugins often causes troubles for people new to Gradle. Custom plugins allow capture of "corporate defined conventions." Deviations from the corporate standard become obvious. Sipe also talked about Gradle's conciseness and being Groovy. Gradle can do anything Groovy can do because it is Groovy. That last point appeals to me. It has always been limiting in Ant to not be able to simply use Java whenever I please.
During his presentation, Sipe referenced the book Continuous Delivery.
I need to invest some more time into playing with Gradle, but Sipe's presentation has led me to believe it is worth the time and effort. Gradle appears to have tremendous potential for building and managing dependencies and its easy integration with Groovy and Ant also make it attractive. Hopefully, the GA release of Gradle 1.0 will occur in the near future.