This document summarizes the evolution of build tools for Java projects from make/bash scripts in 1995 to modern tools like Maven and Gradle. It describes Ant as an improvement over custom build scripts with standardized tasks in 2000. Maven was introduced in 2002 and became popular in 2005 by standardizing dependencies and project layout. Gradle was introduced in 2007 and combines Maven's conventions with a flexible Groovy DSL, supporting multiple languages and customization through plugins.

1. From Ant to Maven to Gradle
a tale of CI tools for JVM

2. Building tools History
~ 1995 BC

3. Building tools History
• 1995 - make / bash / homegrown
• 2000 - Ant
• 2002 – Maven 1
• 2005 – Maven 2
• 2009 – Maven 3
• 2007 - Gradle

4. 1995 - make / bash / IDE / homegrown
Makefile Shell Script

5. Ok ! What’s the problem ?
• Non portable builds
• You remember the promise write once run debug anywhere
• Non standard builds
• Hard to maintain build configuration for large projects

6. 2000 - Ant FTW !
Engineers are lazy so the promises of
• Portable builds
• You just have to write a small file!
• Like Makefile ?
• Yes!
• Ok !
• But …

7. Ant strength points
• ready made functions called tasks
• you can group them in some groups called targets
• you can write your own tasks in java
• a target can depend on other targets

8. Ant strength points
• A simple ant build file

9. Everyone was happy with
But time passed and …

10. But time passed and …

11. Ant weak points
• Hard to read thousands of lines of XML
• Builds grow out of control
• Very hard to maintain build files
• No standard workflow to respect

12. Ant weak points
• We have to create and clean up files an directories ( and we are lazy )
• We have to produce, download and maintain a growing number of
libraries each with it’s own version – all by hand ( this is hard )

13. 2005 – Introducing Maven 2
• Yes I skipped Maven 1 – it was kinda experimental and Ant was the
“de facto standard”

14. Maven advantages
• Dependency management
• Convention over configuration
• Enforced library grouping, naming and versioning
• Easier subproject management

15. Maven advantages
• Simple more concise configuration file

16. Maven advantages
You just have to:
• Declare your dependencies
• Put source files in src/main/java
• Put test files in src/test/java
• Run mvn clean install deploy
• Find your artifact in target folder and optionally deployed to a server

17. Maven disadvantages
I have a custom configuration how do I …
• Modify the project to follow the maven conventions
• Find a plugin which already does that
• Write a plugin to do that

18. Maven disadvantages
But I could wrote my own custom task in Ant

19. Maven solutions for
artifact deployment
• A maven repository
• But there are other types of repositories too:
• A file server (webdav, ftp, sftp, etc)
• Ivy repository ( Ivy is Ant’s replica for dependency management )
• P2 repository ( eclipse )
• Other reposiotories => Custom logic

20. Maven solutions for
custom logic
• Write a maven plugin
• Maven ant plugin – call your ant tasks from maven
• Maven groovy plugin – write groovy code and the plugin will execute
it as part of the build

21. Introducing

22. Gradle advantages
• Builds for: Java, C/C++, Android, Python, etc.
• Best of both worlds
• Convention over configuration achieved through plugins ( we can be lazy )
• Flexibility through a powerful DSL ( we can do stuff in our weird ways )

23. Gradle advantages
Gradle Wrapper
• No need to install gradle – just check the ./gradlew file into your VCS
and you’re good to go
• the only requirement is to have java installed
• Because of ./gradlew we can be sure the build will have the exact
version of gradle which is built for
• useful when you have a CI server and you want to build project A with gradle
2.1 and project B with gradle 2.4

24. Gradle advantages
Gradle application plugin
• No need to concatenate all classes into a giant jar ( maven shade
plugin )
• The plugin will create a directory structure with
• All the libraries needed
• All the resources specified
• A shell script to start the application

25. Gradle DSL
The DSL is actually groovy code with some scripts added to it
• task {} – is a groovy closure so inside it you can write groovy
• Why Groovy? Is a scripting language easy to use that can use all existing Java
libraries; and you can find a java library for anything
• apply plugin: java – is a call for the method apply on the Project
object

26. A simple gradle build file

27. Demo time!

28. Demo time!