Gradle Multi-Project Builds TODEPLETE: Difference between revisions
Line 18: | Line 18: | ||
<span id='Root_Project'></span>The [[Gradle_Settings_Script_and_Settings_Instance#Project_Hierarchy|project hierarchy]] is described in the [[Gradle_Settings_Script_and_Settings_Instance#Project_Hierarchy|settings.gradle]] file of the '''root project'''. This file is required for multi-project builds. The root project build file can be used to configure as much commonality as possible in the [[Gradle_Project_and_Build_Script#allprojects.7B.7D|allprojects{...}]] block, leaving sub-projects to customize only what is specific for them. | <span id='Root_Project'></span>The [[Gradle_Settings_Script_and_Settings_Instance#Project_Hierarchy|project hierarchy]] is described in the [[Gradle_Settings_Script_and_Settings_Instance#Project_Hierarchy|settings.gradle]] file of the '''root project'''. This file is required for multi-project builds. The root project build file can be used to configure as much commonality as possible in the [[Gradle_Project_and_Build_Script#allprojects.7B.7D|allprojects{...}]] block, leaving sub-projects to customize only what is specific for them. | ||
<span id='Sub-Project'></span>A ''sub-project'' is a project that is part of a multi-project hierarchy, and it is not the [[#Root_Project|root project]]. There is a [[Gradle_Project_and_Build_Script#subprojects.7B.7D|subprojects{...}]] script block that can be used to provide configuration for sub-projects only. Sub-project may have their own [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings.gradle]] and [[Gradle_Project_and_Build_Script#Overview|build.gradle]] configuration files, though they are not required: the behavior of sub-project can be configured in the root project's configuration files. | <span id='Sub-Project'></span>A '''sub-project''' is a project that is part of a multi-project hierarchy, and it is not the [[#Root_Project|root project]]. There is a [[Gradle_Project_and_Build_Script#subprojects.7B.7D|subprojects{...}]] script block that can be used to provide configuration for sub-projects only. Sub-project may have their own [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings.gradle]] and [[Gradle_Project_and_Build_Script#Overview|build.gradle]] configuration files, though they are not required: the behavior of sub-project can be configured in the root project's configuration files. | ||
The structure of a hierarchical project can be displayed with: | The structure of a hierarchical project can be displayed with: |
Revision as of 17:06, 19 May 2018
External
- https://docs.gradle.org/current/userguide/multi_project_builds.html
- https://guides.gradle.org/creating-multi-project-builds/
- https://docs.gradle.org/current/userguide/tutorial_java_projects.html#sec:examples
- https://docs.gradle.org/current/userguide/build_lifecycle.html#sec:multi_project_builds
Internal
Overview
A multi-project build is a build where more than one project is built during a single execution run. Multi-project builds are always represented by a tree of Project instances with a single root. Usually, there is a direct mapping between Project tree elements and directories on the file system where the project configuration and files are maintained, but this behavior is configurable.
A project has a name, and a fully qualified path which uniquely identifies it in the hierarchy.
The project hierarchy is described in the settings.gradle file of the root project. This file is required for multi-project builds. The root project build file can be used to configure as much commonality as possible in the allprojects{...} block, leaving sub-projects to customize only what is specific for them.
A sub-project is a project that is part of a multi-project hierarchy, and it is not the root project. There is a subprojects{...} script block that can be used to provide configuration for sub-projects only. Sub-project may have their own settings.gradle and build.gradle configuration files, though they are not required: the behavior of sub-project can be configured in the root project's configuration files.
The structure of a hierarchical project can be displayed with:
gradle projects
Sub-Project
Inter-Project Dependencies
Sub-projects do not automatically expose their artifacts to other sub-projects of the same multi-build project. The dependencies between sub-projects must be declared explicitly in the dependencies{...} script block of the dependent sub-project. For example, if classes that belong to "subproject-B" depend on classes in "subproject-A", then subproject-B build.gradle must contain:
dependencies {
...
implementation project(':subproject-A')
...
}
Multi-Project Build Layout
To Deplete
It is possible to run any task in any subproject with the following syntax:
gradle :<subproject-name>:<task-name>
If you were to spend a lot of time working in one sub-project, changing to that directory and running the build from there is normal. Running a task from that subdirectory will trigger all necessary actions form its dependency projects, thanks to the Gradle task graph implementation.
Project Filtering
Sub-projects to apply specific configuration to can be selected dynamically with an expression. configure can be used with a predicate closure to allow for selective sub-projects to be configured.
configure(subprojects.findAll {it.name == 'subproject-A' || it.name == 'subproject-A'} ) {
apply plugin : ...
dependencies {
...
}
}
Layout
Hierarchical
The project path is assumed to be equal to the relative physical file system path. "include" method argument "project1:child2" is mapped onto a "project1/child2" directory, relative to the root directory of the project. "project1:child2:subchild3" implies three projects: "project1", "project1:child2" and "project1:child2:subchild3".
Flat
A flat layout is introduced by the "includeFlat" method, which takes directory names are argument. These directories need to exist as samplings of the root project directory.