This document discusses why Gradle is a useful build tool. It provides automation, repeatability, and efficiency for software builds. Gradle models builds as a directed acyclic graph (DAG) of tasks, allowing any build process to be represented. It handles common conventions but also allows custom tasks when needed. Gradle aims to fully automate builds, make them repeatable across environments, and only re-execute tasks when necessary to improve efficiency.

1. Why Gradle?
Peter Ledbrook
e: peter@cacoethes.co.uk
w: http://www.cacoethes.co.uk
t: @pledbrook

2. When did it all begin?
• Programmable
machines have a long
history
• Mechanised
instruments
• Looms
Late 18th/early 19th centuries

3. Punched
cards
First used for looms in 18th Century France - Jacquard Loom 1801
IBM introduced punched card format 1928 - 80 columns!
Text mode column width for DOS, Unix etc.
Imagine creating by hand
Keypunch machines (a little like typewriters) for creating them
Errors mean throwing away the card and doing it again
Fortran and Cobol started with punched cards

4. Fixing card decks
What if your cards are dropped on the floor?
This is an IBM 082 Sorter
Automation of a very error-prone manual process

5. Magnetism saves the day!
Finally, R/W data and code. The dawn of text editors.

6. C/C++
Multi-platform
builds!
Compiler
Linker
Source
.so/.dll & .exe

7. Make
*.c: *.o
cc …
myapp: app.o mylib.o …
ld …
+ manual custom dependencies
Focus mainly on compilation and linking
Make has powerful model based on file dependencies
Maintenance was a lot of work

8. Make
*.c: *.o
cc …
myapp: app.o mylib.o …
ld …
What’s this?
+ manual custom dependencies
Tabs were the bane of Make file writers

9. Java
• Compiler handles .java to .class
dependencies
• JAR as ‘module’ unit
• Several standard deployment types
- Applet
- WAR
- Standalone app
Publish == prod server, installer, JAR, zip package, etc.

10. A standard build
Compile Test Package Publish?
A simplification from the days of C
Interesting point: does the packaging actually require the tests to run?

11. What will builds look like in 5
years time?

12. Our builds last a long time
You want a tool that can grow and adapt
One that handles all sorts of build processes
Even Java builds are evolving

13. Model as a graph
Step
Step Step
Step
Step
All build processes can be modeled as a Directed Acyclic Graph (DAG) of steps
This is the Gradle model (a task == a step)

14. But we don’t want to set up all
those steps!

15. Gradle Conventions
apply plugin: "java"
group = "org.example"
version = "0.7.1"
sourceCompatibility = "1.7"
targetCompatibility = "1.7"
Java build conventions
provided by plugin

16. Gradle Conventions
• compileJava (src/main/java)
• compileTestJava (src/test/java)
• test (added as dependency of check)
- test reports in build/reports/test
• jar (added as dependency of assemble)
- created in build/libs
• javadoc

17. Not all builds are the same

18. Java build evolved
Compile Test Package Publish?
Dev setup Run
QA
SCM Tags
Deployment
Docs
Generators
JS + CSS
Builds are incorporating more and more steps
Android is an example of a quite different Java build

19. Custom build
publishPdf
publishGuide
apiDocs
fetchGrailsSource
grails-doc
project
expensive,
so optional
build
A build to generate the Grails user guide
Automation of all steps
No standard tasks
Task graph is a suitable model

20. Mixed build
C/C++
DLL/SO
Java
Debian packages
Executable
Build barrier
Build barrier
I’ve worked with or know of several projects that have native + Java parts

21. Each transfer between different build systems is like a baton handover - with the potential for the baton to be dropped.

22. The build tool should not
dictate the build process

23. Goals of a build
What do we want out of our build processes?

24. Automation
People are fallible
Muscle memory can help
e.g. tying shoe laces
Not usually applicable in software development

25. Automation
• Humans are fallible
• Every manual step adds to the fragility of
the build
• Muscle memory can help, but rarely
applicable
People are fallible
Muscle memory can help
e.g. tying shoe laces
Not usually applicable in software development

26. Mistakes == Lost time
(and possibly money)
Errors made deploying to beta.grails.org and grails.org
Long path between updating source code and starting the server with changes
Stress and downtime

27. Does your build have manual
steps? If so, why?
For example, copying files around, entering parameter values, running external scripts, etc.

28. Custom tasks in Gradle
task publishGuide << {
// Generate HTML from .gdoc
}
build.dependsOn publishGuide
buildSrc/src/groovy/pkg/PublishGuideTask.groovy
pkg.PublishGuideTask in a JAR

29. Don’t reinvent the wheel
http://plugins.gradle.org/
Gradle Plugin Portal
This is searchable
Contains many (but not all) publicly available plugins
You can publish your own too

30. Repeatability

31. Same inputs should result in
same outputs
In other words, repeatable builds
Environment should not be a factor
Does the build behave differently on different platforms?
Consider “works for me” with local Maven cache

32. Depends on tasks
• Are tasks environment-dependent?
• Do system properties or environment
variables have an effect?
• What about number of cores?
• Order of tests?
Gradle can’t help much with this - except for task ordering

33. Task ordering
• mustRunAfter/shouldRunAfter
• No task dependencies
task integTest {
...
}
task packageReports {
mustRunAfter integTest
...
}
`packageReports` does not depend on `integTest`
But if both are executed, `packageReports` must come after `integTest`
shouldRunAfter is less strict - mostly to optimise feedback

34. Task ordering
• finalizedBy
• Ensures execution of the finalizer task
task integTest {
finalizedBy packageReports
...
}
task packageReports {
...
}
`packageReports` does not depend on `integTest`
If `integTest` runs, then `packageReports` will run too, always after `integTest`

35. Gradle cache
• Origin checks
• Artifact checksums
• Concurrency safe
• Avoid mavenLocal()!
Dependency cache can be a big impediment to repeatability

36. Resolution strategy
configurations.all {
resolutionStrategy {
failOnVersionConflict()
force 'asm:asm-all:3.3.1',
'commons-io:commons-io:1.4'
}
Override version to use
for specific dependencies
Fail the build if any
version conflicts
Defaults to ‘newest’ strategy
Fine-grained control over dependency versions
Automatic conflict resolution error-prone

37. Resolution strategy
configurations.all {
eachDependency { details ->
if (details.requested.name == 'groovy-all') {
details.useTarget(
group: details.requested.group,
name: 'groovy',
version: details.requested.version)
}
}
}
Control modules with
different names, same classes
A painful problem to debug

38. Efficiency
Some tasks take significant amounts of time to execute
Why run them each time?
Think Ant/Maven incremental compilation

39. Incremental build
:lazybones-app:compileJava
:lazybones-app:compileGroovy UP-TO-DATE
:lazybones-app:processResources UP-TO-DATE
:lazybones-app:classes UP-TO-DATE
:lazybones-app:jar UP-TO-DATE
:lazybones-app:startScripts UP-TO-DATE
:lazybones-app:installApp UP-TO-DATE
BUILD SUCCESSFUL
Total time: 2.178 secs
UP-TO-DATE
Don’t execute tasks you don’t have to

40. Task inputs & outputs
class BintrayGenericUpload extends DefaultTask {
@InputFile File artifactFile
@Input String artifactUrlPath
@Optional
@Input String repositoryUrl
…⋯
}
Use of annotations makes task support incremental build
Inputs and outputs can be values, files, directories

41. A build should be…
Automated
Repeatable
Efficient

42. On top of this, Gradle gives you
• a rich API for modelling your build process
• full dependency management
• Java ecosystem integration
- IDEs, CI, static analysis tools, etc.
• Flexible publishing (Maven, Ivy,AWS S3)
• Many useful plugins to save you work

43. Summary
• End-to-end process is the build
• 80-20 rule (80% standard 20% custom)
• Automate everything == save time
• Invest in build as if it’s part of your code
base
• Building software requires a rich model

44. Thank you!
e: peter@cacoethes.co.uk
w: http://www.cacoethes.co.uk
t: @pledbrook