WHY USE GRADLE?
Gradle builds are written in its own Groovy based DSL, known as Gradle Build Language. It is a build programming language with features for organizing build logic in a more readable and maintainable form. For instance set of instructions that are being used repeatedly can be extracted in Gradle as a method. This method can be named with appropriate parameters in each of the tasks, thus avoiding rewriting code. Gradle developers cite its closeness to Java in terms of syntax, type system and package structure as the reason behind using Groovy for DSL. The argument is that although Gradle is a general purpose build tool at its core, its main focus is Java projects. Groovy provides the greatest transparency and ease of understanding for Java developers amongst dynamic scripting languages like Python, Groovy and Ruby.
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.
