Gradle

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

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

1.What is this?Big winIt is a full language itself, not a configuration file.

Gradle just provides a lifecycle and some classes to help you

2. How it works?Manages with some classes:- Build process- Dependencies- Project files

USING- Tasks- Projects- Repositories- Dependencies

Key concepts:- BuildScript- Project- Repositories- Tasks- Plugin

2. How it works?

BuildScript

2. How it works?

Setup script to add dependencies on the building process. Ex. plugin dependencies

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.

Repositories

2. How it works?

Defines which are the sources of the possible dependencies. Ex. MavenCentral, jCenter (bintray)

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.

Plugins

2. How it works?

Programs that evaluates during the build process and are able to add behaviour and tasks to the current project.

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

Class DSL

3. DSL Syntax

Class DSL

3. DSL Syntax

Class DSL

3. DSL Syntax

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

5. TaskDeclare a task

5. TaskAdd dependency between tasks

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

5. TaskExecute

./gradlew hellohello

6. Pluginsapply plugin: "name"

where "name" is declared in META-INF in the plugin project.

Same as: project.apply(MyPluginClass)

6. Pluginspublic class MyPlugin extends Plugin<Project> {

@Overridepublic void apply(Project project){}

}

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

7. Android pluginBuild 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

7. Android pluginFlavor

- 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

7. Android pluginDimension

- Mix different flavors in a single one- Descriptor for a flavor

7. Android plugin

Is a = Flavor(s) + BuildType

Variant

ExampleBuild type: debugFlavor: free

Tasks: installFreeDebug, assembleFreeDebug...

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)

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

Black Magic with gradle

When integration with third parties sucks

Compiling libs per flavordependencies {

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

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'] }

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.