Gradle Multi-Project Builds TODEPLETE: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 58: Line 58:




====Project Filtering====
{{External|https://docs.gradle.org/4.7/userguide/multi_project_builds.html#sub:project_filtering}}
Sub-projects to apply specific configuration to can be selected dynamically with an expression. <tt>configure</tt> can be used with a predicate closure to allow for selective sub-projects to be configured.
<syntaxhighlight lang='groovy'>
configure(subprojects.findAll {it.name == 'subproject-A' || it.name == 'subproject-A'} ) {
    apply plugin : ...
    dependencies {
        ...
    }
}
</syntaxhighlight>


====Layout====
====Layout====

Revision as of 17:38, 19 May 2018

External

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 multi-project build can be displayed with:

gradle projects

It is possible to run any task in any sub-project with the following syntax:

 gradle :<sub-project-path>:<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.

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')
    ...
}

Selective Project Configuration

Multi-Project Build Layout

Project Hierarchy

To Deplete

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.