Multi-project Build

Gradle provides support for modulized projects. Because every module in Gradle are called project, we can call this multi-project build.

Modularizing a project

Identify and refactor to modules

The former project structure is shown below.

The original project structure
As we can see, there are model, repository and web modules, we can modularize this project into 3 modules.

• model: Data representation of To-do items
• repository: Storage and retrieval of To-do items

• web: Web components to handle HTTP requests

  
  Multi-project build

Assembling build

By running:

$ gradle projects

in the root path, you can get

 ------------------------------------------------------------
       Root project
       ------------------------------------------------------------
        Root project 'todo'
        No sub-projects

This report shows that you are dealing with a single project build.
We can declare sub-projects by settings.gradle

Introducing settings file

The settings file declares the configuration required to instantiate the project’s hierarchy. By default, this file is named settings.gradle and is created alongside the build.gradle file of the root project.
You can call the include in settings.gradle to add sub-projects.

include 'model'
include 'repository','web'

Settings API

Before Gradle assembles its build, it creates an instance of type settings. The interface Settings is a direct representation of settings.gradle. Its main purpose is to add Project instance that is supposed to participate in the multiproject build.

Settings execution

What phase does the code of the settings file is evaluated and executed? During the initialization before any Project instance is configured.
How to find a settings file? There are two steps.

1. Gradle searches for a settings file in a directory called master with the same nesting level as the current directory.
2. If no settings file is found in step 1, Gradle searches for a settings file in the parent directories, starting from the current directory. In the case of subproject2, the search would be suproject1 > root.
   Step2 is useful for a hierarchical project.

Hierachical VS Flat

It is recommended that you use the hierarchical project.

Configuring sub-projects

You can define common behavior for all projects or all sub-projects.
You can define the order of projects while evaluation, whose default order is alphanumeric.
You can declare project-specific code.

Define specific behavior

Project-specific behavior is defined with the project.

ext.projectIds = ['group': 'com.manning.gia', 'version': '0.1']
// Declaration of extra property projectIds as a map that holds the key-value pairs for group and version; property can be used in subprojects
group = projectIds.group
version = projectIds.version
project(':model') {
   group = projectIds.group
   version = projectIds.version
   apply plugin: 'java'
}
project(':repository') {
   group = projectIds.group
   version = projectIds.version
   apply plugin: 'java'
}
project(':web') {
   group = projectIds.group
   version = projectIds.version
   apply plugin: 'java'
   apply plugin: 'war'
   apply plugin: 'jetty'
   repositories {
      mavenCentral()
}
// Configures each subproject by project path; actual configuration happens in the closure
   dependencies {
      providedCompile 'javax.servlet:servlet-api:2.5'
      runtime 'javax.servlet:jstl:1.1.2'
   } 
}

If you run gradle build for repository, you will end up with a compile error, for repository project depends on model project. You need to declare the dependation between them.

Define project dependencies

project(':model') {
   ...
}
project(':repository') {
   ...
   dependencies {
     compile project(':model')
   }
}
project(':web') {
   ...
   dependencies {
      compile project(':repository')
      providedCompile 'javax.servlet:servlet-api:2.5'
      runtime 'javax.servlet:jstl:1.1.2'
} }

Partial builds

If you execute a task from the root project, it will run all the build code.
If you want to run a partial build, you can use a command-line option -a or --no-rebuild. With the parameter -a, you will avoid the cost of checking dependency projects.
There are some other arguments.

Declare cross-project task dependencies

Default task execution order: the task on the root level of the multi projects build is always executed first. For the subprojects, the execution order is solely determined by the alphanumeric order of the names of the projects: model comes before repository.
You can use dependsOn to change the order.

Define common behaviors

You can use all projects method to define common behaviors for all projects, you can use subprojects to define behaviors for all sub projects.
/ROOT_PATH/build.gradle

allprojects {
   group = 'com.manning.gia'
   version = '0.1'
}
subprojects {
   apply plugin: 'java'
}
project(':repository') {
   dependencies {
      compile project(':model')
   }
}
project(':web') {
   apply plugin: 'war'
   apply plugin: 'jetty'
   repositories {
      mavenCentral()
}
   dependencies {
      compile project(':repository')
      providedCompile 'javax.servlet:servlet-api:2.5'
      runtime 'javax.servlet:jstl:1.1.2'
} }

You can also add specific project configurations in the project's own build.gradle file.