2. Traditional build systems
• Make, autotools
• Ant (build, deploy), ant + ivy (dependency mgmt.)
• Maven (dependency and lifecycle mgmt.)
• Can be extended using plugins
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
abstractions and more flexibility long term.
http://thoughtworks.fileburst.com/assets/technology-radar-october-2012.pdf
2
3. Alternative build systems
• Gradle (DSL + groovy + Ivy)
• Rake (DSL + ruby)
• Apache Buildr (DSL + ruby)
• Scons (DSL + python)
• Simple Build Tool (Scala + DSL)
• All this systems based on a true languages: ruby, python etc.
3
4. Brief Gradle benefits
• You could script parts of the build that were too difficult to describe through "build by convention".
• The general flexibility to define the build and directories the way that seemed to make sense.
• The entire conceptualization of the build process is much cleaner. You not only have dependencies between
modules but you can also define dependencies on tasks, modules, directories. It is already possible to say that one
module depends on the compiled classes of another module as opposed to the output (jar) of the module.
• Each project/module can have multiple "source sets". A "source set" defines a named group of source directories,
output directories, resource directories.
• "how am I going to solve this?" as opposed to "what are the viable options my build tool is going to leave me to
achieve this?"
• "incremental build“. It understands when things have changed and when they have not and when certain portions
of the build are really needed.
• Can publish artifacts to Maven repositories and generate accurate POM.
• IDE project generation (Eclipse – spring tool suite + greclipse / IntelliJ).
https://community.jboss.org/wiki/GradleWhy?_sscc=t
4
5. Gradle usage in real world
• Hibernate
• Grails
• Groovy
• SpringIntegration
• SpringSecurity
5
12. Dependency management
• Groovy use Ivy under the hood + some syntactic sugar
• Support maven and Ivy repositories + custom repositories
• Logical groups of dependencies (compile group, testCompile group)
• Transitive version conflicts (different sl4j-api versions)
configurations.all {
resolutionStrategy {
failOnVersionConflict()
}
}
gradle dependencies
12
13. Testing
• JUnit tests by defaul
• TestNG as well, test.useTestNG()
• Configurable
test {
systemProperty 'sysProp', 'value'
jvmArgs '-Xms256m', '-Xmx512m'
debug = true
ignoreFailures = true
enableAssertions = true
maxParallelForks = 4
forkEvery = 10 // create new thread after 10 tests
}
13
14. Running, publishing
• Run application (apply plugin: ‘application’ )
• Startup scripts (for win and linux)
• Zip archive (with lib folder)
• Publish jar and zip files to repositories (gradle uploadArchives)
• Publish to maven repository
• Publish signed artifacts (PGP only)
14
15. Publish to local maven repository
apply plugin: 'maven'
archivesBaseName = "algorithms"
group = 'com.max.algorithms'
version = '1.0'
uploadArchives {
repositories {
mavenDeployer {
repository(url: 'file:./maven')
}
}
}
15
16. Multi-project builds
• DAG full dependency traversation
• Hierarchical structure
• Flat structure
• Possible to have one build file per multi module project
• Define dependencies between tasks in different projects
• Compile/runtime dependencies between projects
16