Gradle

Gradle Plugins
a. two types: script plugins (by apply from) and binary plugins (by apply plugin-id)
Script plugins are automatically resolved and can be applied from a script on the local filesystem or at a remote location.
binary plugins apply plugins by their plugin id, which is a globally unique identifier, or name, for plugins.
b. two steps: resolve & apply
Resolving a plugin means finding the correct version of the jar which contains a given plugin and adding it the script classpath.
Applying a plugin means actually executing the plugin's Plugin.apply(T) on the Project you want to enhance with the plugin.
c. non-core binary plugins need to be resolved before applied via below 4 ways.
Including the plugin from the plugin portal or a custom repository using the plugins DSL (see Section 27.5.2, “Applying plugins with the plugins DSL”).
Including the plugin from an external jar defined as a buildscript dependency (see the section called “Applying plugins with the buildscript block”).
Defining the plugin as a source file under the buildSrc directory in the project (see Section 43.4, “Build sources in the buildSrc project”).
Defining the plugin as an inline class declaration inside a build script.

Most plugins need to obtain some configuration from the build script. One method for doing this is to use extension objects. The Gradle Project has an associated ExtensionContainer object that helps keep track of all the settings and properties being passed to plugins.

Dependency Management:
1. Dependency configration
In Gradle dependencies are grouped into configurations(A configuration is simply a named set of dependencies). Configurations have a name, a number of other properties, and they can extend each other.Many Gradle plugins add pre-defined configurations to your project.
A project's configurations are managed by a configurations object.

configurations {
    compile {
        description = 'compile classpath'
        transitive = true
    }
    runtime {
        extendsFrom compile
    }
}

2. Dependency types
External module dependency
Client module dependency
Project dependency
File dependency
Gradle API dependency
Local Groovy dependency

Configuration file
settings.gradle file tells Gradle how the project and subprojects are structured.
The root build.gradle is often used to share common configuration between the child projects.

Three Build phases:
Initialization
Configuration
Execution

Properties:
1. System Properties
gradle xxx -DmySystemProp=xxx --> System.properties['someProperty']
2. Project Properties
gradle xxx -PmyProjectProp=xxx --> project.hasProperty('someProperty')
3. ext property

Gradle core objects: Project, Task, Plugin
Project lifecycle
One-one relationship for Project & build.gradle
Steps during build initialization:
1) Create a Settings instance for the build
2) Evaluate the "settings.gradle" script, if present, against the Settings object to configure it.
3) Use the configured Settings object to create the hierarchy of Project instances.
4) Evaluate each Project by executing its "build.gradle" file if present

Gradle features via Project API
project.tasks --> TaskContainer
project.taskGraph --> TaskExecutionGraph
project.configurations --> ConfigurationContainer
project.files --> FileCollection
project.repositories --> ArtifactRepositoryContainer
project.dependencies --> DependencyHandler
project.artifacts --> Artifacthandler
project.extentions --> ExtentionContainer
project.plugins --> PluginContainer

Plugin:
A Plugin represents an extension to Gradle, which applies some configuration to a target object (usually a project)
void apply (T target)
PluginAware: Something that can have plugins applied to it
Implementing Classes: Gradle, Project, Settings
void apply​(Closure closure)
void apply​(Map<String,​?> options)
void apply​(Action<? super ObjectConfigurationAction> action)
 from​(Object script)
    to​(Object... targets)
    plugin​(String pluginId)
    plugin​(Class<? extends Plugin> pluginClass)
PluginManager
PluginContainer
The id of a plugin is specified using a META-INF/gradle-plugins/${id}.properties classpath resource