Gradle Multi-Project Builds TODEPLETE: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 46: Line 46:
{{External|https://docs.gradle.org/4.7/userguide/multi_project_builds.html#sub:project_filtering}}
{{External|https://docs.gradle.org/4.7/userguide/multi_project_builds.html#sub:project_filtering}}


Selective project configuration can be achieved via project filtering, by invoking Project's [https://docs.gradle.org/current/dsl/org.gradle.api.Project.html#org.gradle.api.Project:configure(java.lang.Iterable,%20groovy.lang.Closure) configure(...)] method with a predicate closure that selects specific sub-projects:
Selective project configuration can be achieved via project filtering, by invoking Project's [https://docs.gradle.org/current/dsl/org.gradle.api.Project.html#org.gradle.api.Project:configure(java.lang.Iterable,%20groovy.lang.Closure) configure(...)] method with a predicate closure that selects specific sub-projects, as shown in the example below. The method is executed in the [[Gradle_Concepts#Configuration|configuration phase]], in the order in which it was specified in build.gradle.


<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>

Revision as of 17:53, 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

https://docs.gradle.org/4.7/userguide/multi_project_builds.html#sub:project_filtering

Selective project configuration can be achieved via project filtering, by invoking Project's configure(...) method with a predicate closure that selects specific sub-projects, as shown in the example below. The method is executed in the configuration phase, in the order in which it was specified in build.gradle.

configure(subprojects.findAll {it.name == 'subproject-A' || it.name == 'subproject-A'} ) { 

    apply plugin : ...

    dependencies {
        ...
    }
}

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.