Friday session where we explained what is gradle and some of the hidden features and possibilities that gradle gives to developers to customize their builds in a clean and easy way.
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
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
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
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
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.