THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
As of Maven 3, .x has the capability to perform parallel builds are now added as an experimental feature in maven. The command is as follows:
...
This build-mode analyzes your project's dependency graph and schedules modules that can be built in parallel according to the dependency graph of your project.
The above mentioned thread per cpu core means the number of cores is used as a multiplier
Experimental feature for 3.0!
...
- Surefire with forkMode=never, surefire [2.6,) asserts this.
- maven-modello-plugin, fixed in [1.4,)
- All maven-archiver clients (EAR, EJB, JAR, WAR etc), see httphttps://jiraissues.codehausapache.org/jira/browse/MSHARED-148 related/links section. EAR, EJB, JAR and WAR are fixed in latest version.
...
- Maven Clean Plugin 2.4.1
- Maven Compiler Plugin 2.3.1
- Maven Install Plugin 2.3.1
- Maven Resources Plugin 2.4.3
- Maven Surefire Plugin 2.6
- Maven EAR Plugin 2.4.2
- Maven EJB Plugin 2.3
- Maven JAR Plugin 2.3.1
- Maven WAR Plugin 2.1
- Maven Shade Plugin 1.3.3
- Maven Changes Plugin 2.4
- Maven Checkstyle Plugin 2.6
- Maven Antrun Plugin 1.4
- Maven Assembly Plugin 2.2.1 (not yet released)
- Maven GPG Plugin 1.1
- Maven Plugin Plugin 2.7
- Maven Remote Resources Plugin 1.2.1 (not yet released1.2 is not threadsafe)
- Maven Source Plugin 2.1.2
- maven Enforcer Plugin 1.0.1
Known issues
It is not required to report jiras for these issues:
The console output of both parallel modes is not sorted in any way, which can be a bit confusing. httphttps://jiraissues.codehausapache.org/jira/browse/MNG-2727
Mojo thread safety assertion checklist
...
If a mojo uses a known-non-threadsafe external dependency, you may want to do something like this:
| Code Block |
|---|
public class MyMojo
extends AbstractMojo
{
private static final Object lock = new Object();
public void execute()
{
synchronized( lock)
{
// Main mojo code
}
}
}
|
How Execution is evaluated
Each node in the graph represents a module in a multi-module build, the "levels" simply indicate the distance to the first module in the internal reactor dependency graph. Maven calculates this graph based on declared inter-module dependencies for a multi-module build. Note that the parent maven project is also a dependency, which explains why there is a single node on top of most project graphs. Dependencies outside the reactor do not influence this graph.
For simplicity; let's assume all modules have an equal running time. This build should have level 0 running first, then a fanout of up to 5 parallel on level 1. On level 2 you'll be running 3 parallel modules, and 7 on 3, 5 on level 4.
This goes by declared dependencies in the pom, and there is no good log of how this graph is actually evaluated. (I was hoping to render the actual execution graph, but never got around to finding a cool tool/way to do it - plaintext ascii in the -X log would be one option).
Of course, in real life your modules do not take equal amounts of time. Significant gains are common when the project has one or more "api" modules and dependencies on the "api" modules (and just bring the "impl" version of the module into the actual assembly that will be started). This design normally means your big chunky modules depend on lightweight "api" modules that build quickly.
The parallel build feature rewards "correct" modularizations. If your project has degenerated inter-module dependencies (execessive dependencies inside reactor), you will probably see gains by cleaning up the dependencies.