Gradle is a general-purpose build system written in Groovy that facilitates software building by managing processes, dependencies, and project files. It features a DSL that allows users to define build scripts and tasks, with a full lifecycle process to execute builds and handle various project configurations. The document also discusses the Android plugin, showcasing how to manage build types, flavors, and dimensions while emphasizing the flexibility of defining dependencies and resources per flavor.

1. Gradle

2. 1.What is this?
General purpose build system made in groovy that allows you to execute the needed commands to build software.
Manages:
- Build process
- Dependencies
- Project files

3. 1.What is this?
Similar products:
- Ant
- Maven
- Gant
- Ivy
- Rake
- Buildr
- ...

4. 1.What is this?
Big win
It is a full language itself, not a configuration file.
Gradle just provides a lifecycle and some classes to help you

5. 2. How it works?
Manages with
some classes:
- Build process
- Dependencies
- Project files
USING
- Tasks
- Projects
- Repositories
- Dependencies

6. Key concepts:
- BuildScript
- Project
- Repositories
- Tasks
- Plugin
2. How it works?

7. BuildScript
2. How it works?
Setup script to add dependencies on the building
process. Ex. plugin dependencies

8. Project
2. How it works?
Element that represents the current project and is
considered the top level item. Contains all the
important information, plugins, files and source
directories.

9. Repositories
2. How it works?
Defines which are the sources of the possible
dependencies. Ex. MavenCentral, jCenter (bintray)

10. Tasks
2. How it works?
Pieces of code that are able to perform some action
defined. Tasks can be dependent from each other
and they can receive actions before or after.

11. Plugins
2. How it works?
Programs that evaluates during the build process
and are able to add behaviour and tasks to the
current project.

12. DSL based on Groovy but...
- You can do whatever you can do in the Groovy
language
- Use the DSL to make it look like a configuration
file
3. DSL Syntax

13. Class DSL
3. DSL Syntax

14. Class DSL
3. DSL Syntax

15. Class DSL
3. DSL Syntax

16. 4. Build process lifecycle
- Compile build in .gradle cache
- Execute buildscript
- First round to configure dependencies and source directories
- afterEvaluate execution to generate tasks based on first step
- Execute whatever task you want

17. 5. Task
Declare a task

18. 5. Task
Add dependency between tasks

19. 5. Task
- taks.doFirst
- task.doLast (<<)
- project.findBy..name, path...
- extend tasks

20. 5. Task
Execute
./gradlew hello
hello

21. 6. Plugins
apply plugin: "name"
where "name" is declared in META-INF in the plugin project.
Same as:
project.apply(MyPluginClass)

22. 6. Plugins
public class MyPlugin extends Plugin<Project> {
@Override
public void apply(Project project){
}
}

23. 7. Android plugin
- Android DSL
- Build types
- Flavors
- Dimensions
- Default configuration properties

24. 7. Android plugin
Build type
- Application build configuration
- Default build types are debug and release
DSL: http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.BuildType.html

25. 7. Android plugin
Flavor
- Specific files for the build
- Version code, variables, dimensions
- No needed/No default
DSL: http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ProductFlavor.html

26. 7. Android plugin
Dimension
- Mix different flavors in a single one
- Descriptor for a flavor

27. 7. Android plugin
Is a = Flavor(s) + BuildType
Variant
Example
Build type: debug
Flavor: free
Tasks: installFreeDebug, assembleFreeDebug...

28. 8. Show me the code
Default flavor without
name
Tell the compiler where to
find the tools in the
ANDROID_HOME
Plugin that defines the dsl (library and app)

29. 8. Show me the code
- Searches on those repos defined in
repositories (jcenter, mavenCentral)
- Takes the group:artifact:version
- Allows to define dependencies inside the
project with plain jars

30. Black Magic with gradle
When integration with third parties sucks

31. Compiling libs per flavor
dependencies {
mppNotProductionCompile fileTree(dir: 'mppNonProd', include: '*.jar')
mppProductionCompile fileTree(dir: 'mppProd', include: '*.jar')
}
When third parties give several SDK per platform. As it is a dependency it’s an
unique, so values cannot override the others, you just need to choose what to
compile

32. Use resources per flavor
Usually you can define resources per flavor just making a folder matching the
flavor. In case you need to reuse in a different way you can iterate between flavors
in the sourceSets. For example:
[qaUat, qaApplauseTestersqa, qaMppQaAlpha].each { item ->
item.res.srcDirs = ['res_qa'] }
[prod, prodMppInt, prodMppPreprod, prodMppQa].each { item ->
item.res.srcDirs = ['res_prod'] }

33. Flavours to the infinity
The examples before were using 1 flavor to define free/paid and one for
buildType.
You can define as much as you want: flavorDimensions 'apptype', 'environment','mpayments'
This allows you combinations of:
apptype+environment+mpayments+buildType. BuildType is always the last.
The more flavorDimensions you have, the more number of variants you will be
able to create.