// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[intro_multi_project_builds]]
= Executing Multi-Project Builds

Only the smallest of projects has a single build file and source tree, unless it happens to be a massive, monolithic application. It’s often much easier to digest and understand a project that has been split into smaller, inter-dependent modules. The word “inter-dependent” is important, though, and is why you typically want to link the modules together through a single build.

Gradle supports this scenario through _multi-project_ builds.

For details about authoring _multi-project_ builds, consult the <<multi_project_builds#multi_project_builds,Authoring Multi-Project Builds section of the user manual>>.


[[sec:identifying_project_structure]]
== Identifying project structure

To identify the project structure, you can use `gradle projects` command.
As an example, let's use a multi-project build with the following structure:
----
> gradle -q projects
include::{snippetsPath}/java/multiproject/tests/listProjects.out[]
----

From a user's perspective, multi-project builds are still collections of tasks you can run.
The difference is that you may want to control _which_ project's tasks get executed.
The following sections will cover the two options you have for executing tasks in a multi-project build.


[[sec:executing_tasks_by_name]]
== Executing tasks by name

The command `gradle test` will execute the `test` task in any subprojects, relative to the current working directory, that have that task.
If you run the command from the root project directory, you'll run `test` in _api_, _shared_, _services:shared_ and _services:webservice_.
If you run the command from the _services_ project directory, you'll only execute the task in _services:shared_ and _services:webservice_.

The basic rule behind Gradle's behavior is: execute all tasks down the hierarchy which have this name.
Only complain if there is _no_ such task found in any of the subprojects traversed.

Gradle looks down the hierarchy, starting with the _current dir_, for tasks with the given name and executes them.
One thing is very important to note.
Gradle _always_ evaluates _every_ project of the multi-project build and creates all existing task objects.
Then, according to the task name arguments and the current directory, Gradle filters the tasks which should be executed.
Because of Gradle's <<sharing_build_logic_between_subprojects#sec:convention_plugins_vs_cross_configuration,cross project configuration>>, _every_ project has to be evaluated before _any_ task gets executed.

When you're using the Gradle wrapper, executing a task for a specific subproject by running Gradle from the subproject's directory
doesn't work well because you have to specify the path to the wrapper script if you're not in the project root.
For example, if want to run `build` task for the _webservice_ subproject and you're in the _webservice_ subproject directory,
you would have to run `../../gradlew build`.
The next section shows how this can be achieved directly from the project's root directory.


[[sec:executing_tasks_by_fully_qualified_name]]
== Executing tasks by fully qualified name

You can use task's fully qualified name to execute a specific task in a specific subproject.
For example: `gradle :services:webservice:build` will run the `build` task of the _webservice_ subproject.
The fully qualified name of a task is simply its project path plus the task name.

A project path has the following pattern: It starts with an optional colon, which denotes the root project.
The root project is the only project in a path that is not specified by its name.
The rest of a project path is a colon-separated sequence of project names, where the next project is a subproject of the previous project.
You can see the project paths when running `gradle projects` as shown in <<sec:identifying_project_structure,identifying project structure>> section.

This approach works for any task, so if you want to know what tasks are in a particular subproject,
just use the `tasks` task, e.g. `gradle :services:webservice:tasks`.

Regardless of which technique you use to execute tasks, Gradle will take care of building any subprojects that the target depends on.
You don't have to worry about the inter-project dependencies yourself.
If you're interested in how this is configured, you can read about writing multi-project builds <<multi_project_builds.adoc#multi_project_builds,later in the user manual>>.


That's all you really need to know about multi-project builds as a build user.
You can now identify whether a build is a multi-project one and you can discover its structure.
And finally, you can execute tasks within specific subprojects.


[[sec:multiproject_build_and_test]]
== Multi-Project Building and Testing

The `build` task of the Java plugin is typically used to compile, test, and perform code style checks (if the CodeQuality plugin is used) of a single project.
In multi-project builds you may often want to do all of these tasks across a range of projects.
The `buildNeeded` and `buildDependents` tasks can help with this.

In <<declaring_dependencies_between_subprojects#javadependencies_2,this example>>, the `:services:person-service` project depends on both the `:api` and `:shared` projects.
The `:api` project also depends on the `:shared` project.

Assume you are working on a single project, the `:api` project.
You have been making changes, but have not built the entire project since performing a clean.
You want to build any necessary supporting jars, but only perform code quality and unit tests on the project you have changed.
The `build` task does this.

.Build and Test Single Project
====
[.multi-language-sample]
=====
.Output of **`gradle :api:build`**
----
> gradle :api:build
include::{snippetsPath}/multiproject/dependencies-java/tests/multitestingBuild.out[]
----
=====
====

If you have just gotten the latest version of source from your version control system which included changes in other projects that `:api` depends on, you might want to not only build all the projects you depend on, but test them as well.
The `buildNeeded` task also tests all the projects from the project dependencies of the testRuntime configuration.

.Build and Test Depended On Projects
====
[.multi-language-sample]
=====
.Output of **`gradle :api:buildNeeded`**
----
> gradle :api:buildNeeded
include::{snippetsPath}/multiproject/dependencies-java/tests/multitestingBuildNeeded.out[]
----
=====
====

You also might want to refactor some part of the `:api` project that is used in other projects.
If you make these types of changes, it is not sufficient to test just the `:api` project, you also need to test all projects that depend on the `:api` project.
The `buildDependents` task also tests all the projects that have a project dependency (in the testRuntime configuration) on the specified project.

.Build and Test Dependent Projects
====
[.multi-language-sample]
=====
.Output of **`gradle :api:buildDependents`**
----
> gradle :api:buildDependents
include::{snippetsPath}/multiproject/dependencies-java/tests/multitestingBuildDependents.out[]
----
=====
====

Finally, you may want to build and test everything in all projects.
Any task you run in the root project folder will cause that same named task to be run on all the children.
So you can just run `gradle build` to build and test all projects.
