Most developers prefer to spend their time writing code instead of performing build script maintenance. Build scripting may be an essential part of the software development process, but it often lacks maintainability which makes applying and deploying changes a tedious job. So it’s important to make sure your build system encourages simplicity and that changes can be made in a fast and straightforward way. Industry standards Ant and Maven are not quite up to the task; Gradle is a better alternative. This presentation introduces Gradle – a modern build system that supports all JVM Languages – and shares the result of the Ant-to-Gradle migration that was performed at ‘Nederlandse Spoorwegen’ (or NS - Dutch Railways). The session will focus on the challenges we faced while trying to replace Ant scripting with the Gradle equivalent and how we handled them. After attending this session, you will have a good understanding of Gradle, its possibilities and its pros and cons compared to Ant and Maven. On top of that, you will be able to migrate your own project to Gradle, even if your project has a huge code base or relies on ancient technologies. The lessons we learnt at NS could be very helpful to your own situation.

1. Migrating 25K lines of Ant
scripting to
Gradle
Hanno Embregts
May 26, 2016 - Sofia, Bulgaria
@hannotify

2. Who is this guy?

3. Who is this guy?

4. Who is this guy?

5. We will consult these 3 experts
Linus Torvalds
creator of Linux & Git

6. We will consult these 3 experts
Linus Torvalds Mark Reinhold
creator of Linux & Git Java's chief architect

7. We will consult these 3 experts
Linus Torvalds Mark Reinhold Louis van Gaal
creator of Linux & Git Java's chief architect manager of
Manchester United

8. We will consult these 3 experts
Linus Torvalds Mark Reinhold Louis van Gaal
creator of Linux & Git Java's chief architect former manager of
Manchester United

9. A history of build
automation

10. A history of build automation

11. A history of build automation
it all started with a command-line call to the compiler

12. A history of build automation
it all started with a command-line call to the compiler
but multi-module projects posed a problem due to order
requirements

13. A history of build automation
it all started with a command-line call to the compiler
but multi-module projects posed a problem due to order
requirements
Make (1977) - define builds with Makefiles

14. A history of build automation
it all started with a command-line call to the compiler
but multi-module projects posed a problem due to order
requirements
Make (1977) - define builds with Makefiles
Ant (2000), Maven (2004) - define builds with XML

15. XML

16. XML
Let's start by being nice:

17. XML
Let's start by being nice:
excels at expressing hierarchical data

18. XML
Let's start by being nice:
excels at expressing hierarchical data
but...

19. XML
Let's start by being nice:
excels at expressing hierarchical data
but...
build scripting logic doesn't easily fit a hierarchy

20. XML
Let's start by being nice:
excels at expressing hierarchical data
but...
build scripting logic doesn't easily fit a hierarchy
often it consists of conditional and repeating logic

21. XML
Let's start by being nice:
excels at expressing hierarchical data
but...
build scripting logic doesn't easily fit a hierarchy
often it consists of conditional and repeating logic
which can be expressed more concisely in a programming
language

22. What does Linus think of XML?

23. What does Linus think of XML?
( )
XML is crap. Really. There are no excuses.
XML is nasty to parse for humans, and it's a
disaster to parse even for computers. There's
just no reason for that horrible crap to exist.
https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

24. Changes in requirements
Past

25. Changes in requirements
Past
compiling

26. Changes in requirements
Past
compiling
packaging

27. Changes in requirements
Present

28. Changes in requirements
Present
one project, multiple programming languages

29. Changes in requirements
Present
one project, multiple programming languages
compiling

30. Changes in requirements
Present
one project, multiple programming languages
compiling
running automated tests

31. Changes in requirements
Present
one project, multiple programming languages
compiling
running automated tests
packaging

32. Changes in requirements
Present
one project, multiple programming languages
compiling
running automated tests
packaging
integrating code as early as possible

33. Changes in requirements
Present
one project, multiple programming languages
compiling
running automated tests
packaging
integrating code as early as possible
deploying software to TAP

34. Build tools:
head to head

35. Ant vs. Maven according to Mark

36. Ant vs. Maven according to Mark
( )
What's the difference between Ant and
Maven?
https://www.parleys.com/tutorial/devoxx-fireside-chat

37. Ant vs. Maven according to Mark
( )
What's the difference between Ant and
Maven? The creator of Ant has apologized.
https://www.parleys.com/tutorial/devoxx-fireside-chat

38. Build tools head-to-head
Ant Maven Gradle

39. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL

40. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in

41. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple

42. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple
pre-defined structure absent present present

43. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple
pre-defined structure absent present present
custom structure n/a complex simple

44. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple
pre-defined structure absent present present
custom structure n/a complex simple
verbosity high average low

45. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple
pre-defined structure absent present present
custom structure n/a complex simple
verbosity high average low
learning curve shallow steep average

46. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
multi-module builds complex simple simple
pre-defined structure absent present present
custom structure n/a complex simple
verbosity high average low
learning curve shallow steep average
build order depends-on lifecycles directed acyclic graph

47. Market share of build tools @
Devoxx Belgium

48. What is Gradle?

49. What is Gradle?

50. What is Gradle?
build system for the JVM

51. What is Gradle?
build system for the JVM
in development since 2009

52. What is Gradle?
build system for the JVM
in development since 2009
has become popular quickly due to being the default
Android build system

53. What is Gradle? (2)

54. What is Gradle? (2)
define builds in Groovy-based DSL

55. What is Gradle? (2)
define builds in Groovy-based DSL
build by convention

56. What is Gradle? (2)
define builds in Groovy-based DSL
build by convention
customization is easy

57. What is Gradle? (2)
define builds in Groovy-based DSL
build by convention
customization is easy
plugins offer additional features

58. What is Gradle? (2)
define builds in Groovy-based DSL
build by convention
customization is easy
plugins offer additional features
to support different (JVM) languages
to support various integration tooling

59. What is Gradle? (3)

60. What is Gradle? (3)
incremental builds

61. What is Gradle? (3)
incremental builds
widely supported

62. What is Gradle? (3)
incremental builds
widely supported
fast and efficient

63. What is Gradle? (3)
incremental builds
widely supported
fast and efficient
advanced dependency management

64. What is Gradle? (3)
incremental builds
widely supported
fast and efficient
advanced dependency management
directed acyclic graph

65. What is Gradle? (3)
incremental builds
widely supported
fast and efficient
advanced dependency management
directed acyclic graph
"Ant's flexiblity, Maven's structure"

66. Define your build in Groovy / the
Gradle DSL

67. Define your build in Groovy / the
Gradle DSL
no XML (tell Linus)

68. Define your build in Groovy / the
Gradle DSL
no XML (tell Linus)
Gradle DSL offers a build-oriented model

69. Sample Gradle build file
apply plugin: 'java'
group = 'org.gradle.example'
version = '1.0.0'
sourceCompatibility = targetCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
compile 'org.slf4j:slf4j-api:1.7.21'
runtime 'org.slf4j:slf4j-simple:1.7.21'
testCompile 'junit:junit:4.12'
}
task sourceJar(type: Jar) {
classifier = 'sources'
from sourceSets.main.allSource
}

70. Build by convention
src
main
test
java
resources
java
resources
build
classes
reports
main
test
tests
test-results
inputs outputs

71. Overriding conventions is easy

72. Overriding conventions is easy
define repositories

73. Overriding conventions is easy
define repositories
customize task behaviour

74. Overriding conventions is easy
define repositories
customize task behaviour
customize build order

75. Overriding conventions is easy
define repositories
customize task behaviour
customize build order
define build logic for subprojects specifically

76. Overriding conventions is easy
define repositories
customize task behaviour
customize build order
define build logic for subprojects specifically
define brand new tasks or re-use existing ones

77. Extending build logic with
plugins

78. Extending build logic with
plugins
loads of stuff at .plugins.gradle.org

79. Extending build logic with
plugins
loads of stuff at .
or build your own plugin to address specific requirements
plugins.gradle.org

80. Extending build logic with
plugins
loads of stuff at .
or build your own plugin to address specific requirements
in Java, Scala or Groovy
plugins.gradle.org

81. Widely supported

82. Fast & efficient

83. Fast & efficient
caching of build plan and dependencies

84. Fast & efficient
caching of build plan and dependencies
incremental building

85. Fast & efficient
caching of build plan and dependencies
incremental building
running tasks in parallel

86. Directed acyclic graph

87. Getting Started

88. Getting Started

89. Getting Started
define build task

90. Getting Started
define build task
extend existing build task

91. Getting Started
define build task
extend existing build task
define advanced task with Groovy

92. Getting Started
define build task
extend existing build task
define advanced task with Groovy
import tasks through plugins

93. Getting Started
define build task
extend existing build task
define advanced task with Groovy
import tasks through plugins
e.g. the Java-plugin

94. Getting Started
define build task
extend existing build task
define advanced task with Groovy
import tasks through plugins
e.g. the Java-plugin
define slot in build order

95. How does Gradle handle...?

96. How does Gradle handle...?
a Java project with its dependencies

97. How does Gradle handle...?
a Java project with its dependencies
running unit tests

98. How does Gradle handle...?
a Java project with its dependencies
running unit tests
computing code coverage

99. How does Gradle handle...?
a Java project with its dependencies
running unit tests
computing code coverage
running an existing Ant-target (see next example)

100. A Java project with Ant, Maven
en Gradle

101. A Java project with Ant, Maven
en Gradle
build tool overkill

102. Importing existing Ant targets
ant.importBuild 'build.xml'

103. DIY Profiling

104. DIY Profiling

105. Gradle at NS
(Dutch Railways)

106. Gradle at NS (Dutch Railways)

107. Gradle at NS (Dutch Railways)
not at all a 'greenfield project'!

108. Gradle at NS (Dutch Railways)
not at all a 'greenfield project'!
1 million lines of code

109. Gradle at NS (Dutch Railways)
not at all a 'greenfield project'!
1 million lines of code
over 25,000 lines of Ant scripting

110. Gradle at NS (Dutch Railways)
not at all a 'greenfield project'!
1 million lines of code
over 25,000 lines of Ant scripting
30 software developers

111. Gradle at NS (Dutch Railways)
not at all a 'greenfield project'!
1 million lines of code
over 25,000 lines of Ant scripting
30 software developers
system behaves like a monolith

112. Migration strategy

113. Migration strategy
divide the project into components according to
functionality

114. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part

115. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part
focus on code that is used regularly (i.e. on a daily basis)

116. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part
focus on code that is used regularly (i.e. on a daily basis)
verify after each step that:

117. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part
focus on code that is used regularly (i.e. on a daily basis)
verify after each step that:
results are exactly the same as before
no problems occur in existing Ant code

118. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part
focus on code that is used regularly (i.e. on a daily basis)
verify after each step that:
results are exactly the same as before
no problems occur in existing Ant code
don't fool yourself: not every single line of Ant code should
be replaced

119. Migration strategy
divide the project into components according to
functionality
start Gradling at a small, isolated part
focus on code that is used regularly (i.e. on a daily basis)
verify after each step that:
results are exactly the same as before
no problems occur in existing Ant code
don't fool yourself: not every single line of Ant code should
be replaced
Ant projects are 'first class citizens'

120. Challenges

121. Challenges
dependency spaghetti

122. Challenges
dependency spaghetti
collaboration with existing Ant code

123. Challenges
dependency spaghetti
collaboration with existing Ant code
continuous integration & delivery

124. Migration result

125. Migration result
a component's responsibility has become clearer

126. Migration result
a component's responsibility has become clearer
a build will only run if the particular component has
changed

127. Migration result
a component's responsibility has become clearer
a build will only run if the particular component has
changed
run unit test in parallel (Gradle decides when)

128. Migration result
a component's responsibility has become clearer
a build will only run if the particular component has
changed
run unit test in parallel (Gradle decides when)
dependencies behave transitively

129. Migration result (lines of code)

130. Migration result (lines of code)
Language Lines of code (before) Lines of code (after)
Ant over 25,000 about 15,000
Gradle 0 1,232

131. What does Louis think of migrating all Ant
code?

132. What does Louis think of migrating all Ant
code?
( )
In the Netherlands they say: "That is another
cook."
https://youtu.be/x-QRqOndbzw

133. Wrap-up

134. Wrap-up
Ant & Maven:

135. Wrap-up
Ant & Maven:
require hard-to-maintain code

136. Wrap-up
Ant & Maven:
require hard-to-maintain code
the purpose of a code fragment is not clearly evident

137. Wrap-up
Ant & Maven:
require hard-to-maintain code
the purpose of a code fragment is not clearly evident
often fail to address changing requirements

138. Wrap-up
Ant & Maven:
require hard-to-maintain code
the purpose of a code fragment is not clearly evident
often fail to address changing requirements
rely heavily on XML

139. Wrap-up
Ant & Maven:
require hard-to-maintain code
the purpose of a code fragment is not clearly evident
often fail to address changing requirements
rely heavily on XML
Gradle is a better alternative

140. Wrap-up (2)
Gradle offers structure and flexibility

141. Wrap-up (2)
Gradle offers structure and flexibility
tries to combine the power of Ant and Maven

142. Wrap-up (2)
Gradle offers structure and flexibility
tries to combine the power of Ant and Maven
integrates with (almost) anything

143. Wrap-up (3)
So no drawbacks whatsoever?

144. Wrap-up (3)
So no drawbacks whatsoever?
Gradle spends a lot of time on configuration parsing (but
this has steadily improved in the past year)

145. Wrap-up (3)
So no drawbacks whatsoever?
Gradle spends a lot of time on configuration parsing (but
this has steadily improved in the past year)
developers need to get used to it

146. Wrap-up (3)
So no drawbacks whatsoever?
Gradle spends a lot of time on configuration parsing (but
this has steadily improved in the past year)
developers need to get used to it
migrating existing scripting is a lot of work

147. Should my project use Gradle?
A brand-new project?

148. Should my project use Gradle?
A brand-new project?
just do it

149. Should my project use Gradle?
A brand-new project?
just do it
do it RIGHT NOW

150. Should my project use Gradle?
An existing project?

151. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)

152. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)
Any technical debt to solve?

153. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)
Any technical debt to solve?
use an artifact repository and remove duplicates

154. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)
Any technical debt to solve?
use an artifact repository and remove duplicates
divide your project into multiple components

155. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)
Any technical debt to solve?
use an artifact repository and remove duplicates
divide your project into multiple components
define a clear structure in your build logic

156. Any questions?

157. Further reading
"Why Build Your Java Projects with Gradle Rather than Ant
or Maven?"
by Benjamin Muschko
( )
Gradle User Guide
( )
Gradle Build Language Reference
( )
'Gradle Getting Started' project @ GitHub
( )
'Build Tool Overkill' project @ GitHub
( )
http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608
http://gradle.org/docs/current/userguide/userguide.html
http://gradle.org/docs/current/dsl/index.html
https://github.com/hannoembregts/gradle-getting-started
http://github.com/hannoembregts/build-tool-overkill

158. Thank You :)
You can contact me at:
@hannotify
hanno.embregts@infosupport.com