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 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 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.
7. We will consult these 3 experts
Linus Torvalds
creator of Linux & Git
8. We will consult these 3 experts
Linus Torvalds Mark Reinhold
creator of Linux & Git Java's chief architect
9. 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
10. 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
13. Changes in requirements
Present
one project, multiple programming languages
compiling
running automated tests
packaging
integrating code as early as possible
deploying software to TAP
16. 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
18. 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
21. Ant vs. Maven according to Mark
( )
What's the difference between Ant and
Maven?
https://www.parleys.com/tutorial/devoxx-fireside-chat
22. 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
25. Build tools head-to-head
Ant Maven Gradle
build script format XML XML Groovy / DSL
dependencies with Ivy built-in built-in
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
33. 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
35. 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)
36. 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
37. 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'
39. 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
40. 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
46. 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
47. 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
48. Wrap-up (2)
Gradle offers structure and flexibility
tries to combine the power of Ant and Maven
integrates with (almost) anything
50. 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
55. Should my project use Gradle?
An existing project?
Will you benefit from Gradles key features? (better
performance, maintainability, less verbose, ...)
56. 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?
57. 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
59. Further reading
"Why Build Your Java Projects with Gradle Rather than Ant
or Maven?"
by Benjamin Muschko
( )
Gradle User Guide
( )
Gradle Build Language Reference
( )
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
60. Thank you :)
You can contact me at:
@hannotify
hanno.embregts@infosupport.com
