3. Recognition by ThoughtWorks
“Two things have caused fatigue with XML-based build tools like Ant and Maven: too
many angry pointy braces and the coarseness of plug-in architectures. While syntax
issues can be dealt with through generation, plug-in architectures severely limit the
ability for build tools to grow gracefully as projects become more complex. We have
come to feel that plug-ins are the wrong level of abstraction, and prefer language-
based tools like Gradle and Rake instead, because they offer finer-grained abstrac-
tions and more flexibility long term.”
5. Convention over Configuration - Build Cycle
Ant was cool but it has maintainability issues, duplicated code.
Maven picks up and idea of convention over configuration. Repeated steps are
standardized. Maven’s core logic can be extended with plugins
Maven has life cyclye; Compile, unit and integration tests, assembling the
artifact, deploying the artifact to local repo, releasing the artifact to remote repo.
Dependency Management over maven central
6. Shortcomings - Maven “My way or Highway”
● Maven proposes a default structre and lifecycle for a project that often is
too restrictive
● Writing custom extensions for maven is hard. You must learn MOJO
● Plugin versions may be trouble for your environment.
7. Which one would you prefer?
Flexibility and extensibility but get weak project standardization, tons of
boilerplate code no support for dependency management by picking Ant;
Or You go with maven, which offers a convention over configuration approach
and a seamlessly integrated dependency manager, but an overly restrictive
mindset and cumbersome plugin system.
Or A build tool that offers you both like Gradle!
8. Here comes Gradle
Groovy instead of XML is
declerative, readable, and
it clearly express the
intention
9. What is possible with Gradle while it is impossible with others
Directed Acyclic Graph: In maven goals must depend on each other even if they have no dependencies, in gradle must not
Task Exclusion: In gradle you exclude any task from being run and all its dependend tasks
Task Ordering: Gradle supports shouldRunAfter, mustRunAfter operations
Task Dependency Inference: Gradle aware of what it produce. Any task that has java bin directory as input will automatically trigger compileJava.
True Multi Task Execution: You can specify multiple tasks when executing the build and no task in the resulting DAG is executed twice
Dry Run: Show tasks in which order without executing them Ex: gradle -m clean compile
Build automatically when sources change,
Declarative DSL
10. Integration With Other Build Tools
Gradle builds are 100%compatible with Maven and Ivy Repos. You can retrieve and publish your own artifacts. Also
Gradle provides converter for existing maven builds
11. Deployment Pipline
● Compile the code
● Runing unit and integration tests
● Performing static code analysis and generating test coverage
● Creating the distribution
● Provisioning the target environment
● Deploying the deliverable
● Performing smoke and automated functional tests
13. Gradle Daemon
When using gradle day to day basis, you’ll find yourself having to run your build
repetitvely. Each time you initiate a build, the JVM has to be started, Gradle
dependency’s has to be loaded into class loader, and the project model has to be
constructed. This procedure usually takes 2 seconds.
Gradle daemon to the rescue!
$ ~/.gradle/gradle.properties
org.gradle.daemon=true
