Gradle can handle smallest and largest projects easily. Small projects have a single build file and a source tree. It is very easy to digest and understand a project that has been split into smaller, inter-dependent modules. Gradle perfectly supports this scenario that is multi-project build.
Structure for Multi-project Build
Such builds come in all shapes and sizes, but they do have some common characteristics, which are as follows−
- A settings.gradle file in the root or master directory of the project.
- A build.gradle file in the root or master directory.
- Child directories that have their own *.gradle build files (some multi-project builds may omit child project build scripts).
For listing all the projects in the build file, you can use the following command.
C:\> gradle -q projects
Output
You will receive the following output −
------------------------------------------------------------ Root project ------------------------------------------------------------ Root project 'projectReports' +--- Project ':api' - The shared API for the application \--- Project ':webapp' - The Web application implementation To see a list of the tasks of a project, run gradle <project-path>:tasks For example, try running gradle :api:tasks
The report shows the description of each project, if specified. You can use the following command to specify the description. Paste it in the build.gradle file.
description = 'The shared API for the application'
General Build Configuration
In a build.gradle file in the root_project, general configurations can be applied to all projects or just to the sub projects.
allprojects {
group = 'com.example.gradle'
version = '0.1.0'
}
subprojects {
apply plugin: 'java'
apply plugin: 'eclipse'
}
This specifies a common com.example.gradle group and the 0.1.0 version to all projects. The subprojects closure applies common configurations for all sub projects, but not to the root project, like the allprojects closure does.
Configurations and Dependencies
The core ui and util subprojects can also have their own build.gradle file, if they have specific needs, which are not already applied by the general configuration of the root project.
For instance, the ui project usually has a dependency to the core project. So the ui project needs its own build.gradle file to specify this dependency.
dependencies {
compile project(':core')
compile 'log4j:log4j:1.2.17'
}
Project dependencies are specified with the project method.