Build Lifecycle
docs.gradle.org/current/userguide/build_lifecycle.html
2 Users
0 Comments
11 Highlights
0 Notes
Tags
Top Highlights
The settings file is determined by Gradle via a naming convention
Gradle determines which projects are going to take part in the build, and creates a Project instance for each of these projects.
A multi-project build must have a settings.gradle file in the root project of the multi-project hierarchy. It is required because the settings file defines which projects are taking part in the multi-project build
For a build script, the property access and method calls are delegated to a project object. Similarly property access and method calls within the settings file is delegated to a settings object.
Gradle creates a Project object for every project taking part in the build. For a multi-project build these are the projects specified in the Settings object (plus the root project). Each project object has by default a name equal to the name of its top level directory, and every project except the root project has a parent project. Any project may have child projects.
This example uses method Project.afterEvaluate() to add a closure which is executed after the project is evaluated (ie. the end of the configuration phase).
Gradle is an example of dependency based programming: you define tasks and dependencies between tasks. Gradle guarantees that these tasks execute in the order of their dependencies. Your build scripts and plugins configure this dependency graph.
Some build tools assemble a task graph as they execute tasks.
Both plugins and your own build scripts contribute to the task graph via the task dependency mechanism.
Within each project, tasks form a Directed Acyclic Graph (DAG).
Ready to highlight and find good content?
Glasp is a social web highlighter that people can highlight and organize quotes and thoughts from the web, and access other like-minded people’s learning.