Build Automation with Gradle

Administrator - 05 April 2012 - 12min
Administrator - 05 April 2012 - 12min
GRADLE BUILD FILE
Gradle uses Gradle Build File as the build script for a project. It is Gradle’s substitute to Maven’s pom.xml and Ant’s build.xml. The file is actually a build configuration script rather than a build script. The Gradle command looks for this file to start the build.
There are two basic building blocks in Gradle- projects and tasks. Project represents any component of the software that can be built. For instance a library JAR, a web application WAR or a distribution ZIP assembled from JARs produced by various projects. It could also be something to be done, like deploying the application to various environments. A task represents an atomic piece or work that a build performs, like deleting the older classes, compiling some classes, creating a JAR, generating a Javadoc or publishing archives to a repository. Thus, tasks are the building blocks of builds in Gradle.
To illustrate a few things that stood out for us while evaluating Gradle, Gradle build scripts are made up of code and can be used to leverage the power and flexibility of Groovy. Thus, a build can have easy to read, reusable code blocks like :
task upper << {
String someString = ‘mY_nAmE’
println “Original: ” + someString
println “Upper case: ” + someString.toUpperCase()
}
output:
> Gradle -q upper
Original: mY_nAmE
Upper case: MY_NAME
Iterations can be done with ease when needed, example:
task count << {
4.times { print “$it ” }
}
output:
> Gradle -q count
0 1 2 3
Methods can be extracted out of the logic and reused, example:
task checksum << {
fileList(‘../tempFileDirectory’).each {File file ->
Ant.checksum(file: file, property: “cs_$file.name”)
println “$file.name Checksum: ${Ant.properties[“cs_$file.name”]}”
}
}
task loadfile << {
fileList(‘../tempFileDirectory’).each {File file ->
Ant.loadfile(srcFile: file, property: file.name)
println “I’m fond of $file.name”
}
}
File[] fileList(String dir) {
file(dir).listFiles({file -> file.isFile() } as FileFilter).sort()
}
Another point to note here is the use of Ant tasks (Ant.checksum and Ant.loadfile). This demonstrates how Ant tasks are treated in Gradle as first class citizens. The Java plugin that comes with Gradle’s distribution is also a neat addition and reinforces the claim of useful build-by-convention support. It defines a bunch of conventional build tasks like clean, compile, test and assemble for Java projects.
In conclusion, Gradle has the potential to replace the existing build tools and processes in a big way. However, the move from existing systems to Gradle has understandably been limited across projects. This can be due to the small yet measurable learning curve that comes with moving to Gradle, the relatively low importance attributed to build systems in a project or developers preferring to use systems that they’re already comfortable with. Gradle is definitely an option worth considering, if you are going to start a new project, or your current build tools aren’t cutting it for you anymore.
"Interesting. I am intrigued by the line "The file is actually a build configuration script rather than a build script". Would explore if Gradle can offer facility to configure a system (including setting up the software stack for running the system). Thanks.".