Gradle build scripts use a Groovy-based domain-specific language rather than XML. Build scripts contain initialization, configuration, and execution sections. Tasks represent individual jobs like compiling or packaging and can depend on each other. The Gradle build lifecycle runs tasks in the proper order based on dependencies. Common tasks include compiling, testing, packaging, and publishing artifacts to repositories.

2. Gradle build scripts are not written in the traditional XML, but in a domain-specific language (DSL) based on Groovy
That does not mean you need to know Groovy to get started with your build scripts.

3. • Initialization: This is where the Project instance is created. If there are multiple modules each of them must
have their own build.gradle file.
• Configuration: creating and configuring all the tasks for every project object.
• Execution: Which tasks should be executed depends on the arguments passed for starting the build
and what the current directory is.

6. Working with Repositories
http://jcenter.bintray.com/
http://mvnrepository.com/
http://search.maven.org/
Central and jcenter
Maven repositories
Ivy repositories

7. Artifacts
Must include the appropriate meta data.
Can be identified and retrieved by a unique set of coordinates.
If an artifact has dependencies of its own, that is also specified.

8. Declaring Dependencies
specific dependency
Group of dependencies
File Collection
File Tree

9. Test dependency
Commands

10. Tasks
A task represents some atomic piece of work which a build performs. This might be compiling some classes,
creating a JAR, generating Javadoc, or publishing some archives to a repository.

11. task count << {
4.times { println "$it " }
}
task upper << {
String someString = 'mY_nAmE'
println "Original: " + someString
println "Upper case: " + someString.toUpperCase()
}
task hellos << {
println ’Hello'
}
hellos.doFirst {
println ’Fist Hello'
}
hellos.doLast {
println ’Last Hello'
}
hellos << {
println ‘Last Hello shortcut'
}
task putOnSocks {
doLast {
println "Putting on Socks."
}
}
task putOnShoes {
dependsOn "putOnSocks"
doLast {
println "Putting on Shoes."
}
}
task eatBreakfast {
finalizedBy "brushYourTeeth"
doLast{
println "Om nom nom breakfast!"
}
}
task brushYourTeeth {
doLast {
println "Brushie Brushie Brushie."
}
}

12. task takeShower {
doLast {
println "Taking a shower."
}
}
task putOnFragrance {
shouldRunAfter "takeShower"
doLast{
println "Smellin' fresh!"
}
}
task getReady {
// Remember that when assigning a collection to a property, we need the
// equals sign
dependsOn = ["takeShower", "eatBreakfast", "putOnShoes"]
}
4.times { counter ->
task "task$counter" << {
println "I'm task number $counter"
}
}
task0.dependsOn task1, task2, task3
task copyDocs(type: Copy) {
from
'/Users/pborrayo/GradlePJ/images'
include "*.*"
into
'/Users/pborrayo/GradlePJ/banners'
}
./gradlew -q

13. Typed Tasks
Interacting With The File System
Troubleshooting and Logging
Custom Task
Incremental Builds
Parameterising Your Build
Gradle DSL References
Locating tasks

14. Build Type and a Product Flavor. The two are
mechanically similar, but conceptually orthogonal. Build
Types are typically transparent to users and are only
important to you as a developer, whereas Product Flavors
control features that are visible to end users. Build Types
are used to control how our app is built and packaged. By
default, every Android app has two Build Types, debug
and release.

15. the Android Gradle plugin makes is very simple for us to
declare product flavors for our app. Additionally, we've
learned that the Android plugin creates source sets for
each of our flavors, automatically. These source sets work
just like source sets for regular Java projects. In additional
to having unique source directories for each source set,
we can also assign them unique dependencies.

17. http://michael-huang.logdown.com/posts/293691-building-java-with-gradle
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html
Links suggestions