As of Maven 3 beta 1, parallel builds are now added as an experimental feature in maven. The command is as follows:
mvn -T 4 clean install # Builds with 4 threads
mvn -T 1C clean install # 1 thread per cpu core
mvn -T 1.5C clean install # 1.5 thread per cpu core
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.
There is also an additional (more experimental mode) build mode called "Weave" mode that can be activated by appending a "W" to the commands above, as in -T 1CW. This builds the reactor phase-by-phase in dependency order instead of completing the full modules before proceeding to the next module(s). Your expected performance gain can vary quite dramatically according to your project structure/build architecture, and weave mode may not always be faster than regular parallel. Weave mode is still subject to changes, and may even be removed entirely.
Experimental feature in beta-version !
The use of beta-versions for production systems is generally discouraged. The parallel build functionality is brand new, and although they are tested with quite a few projects they do not have the general wisdom accumulated by running on multiple project types on multiple platforms within the community. So take care.
What performance boost can be expected ?
This depends greatly on your module structure, but the following observations have been made:
- 20-50% speed improvement is quite common.
- Distributing tests among your modules is likely to improve performance, putting all your tests in one module decreases it - unless you
run one of the parallel surefire test providers. - Running tests in parallel within a single surefire-instance is a little different from running multiple surefire-runs (from separate projects),
since there will be different classloaders. Remember that tcp/ip ports and files are still singletons. - For builds with evenly distributed tests (in the modules), weave mode has an advantage over parallel mode.
- When running with -DskipTests, the difference between parallel and weave tends to be marginal.
Plugin/Settings compatibility
The functionality within the Maven3 core is thread safe and well behaved, but the maven ecosystem consists of a large number of subsystems, and a lot of plugins have a large number of dependencies. Not all of these plugins/libraries were written with thread safety in mind. As of beta-2 maven 3 will warn noisily of any plugins present in the build that are not @threadSafe.
The following plugins/settings are KNOWN to have incompatibilities when running any of the parallel modes:
- Surefire with forkMode=never, surefire [2.6,) asserts this.
- maven-modello-plugin, fixed in [1.4,)
- All maven-archiver clients (ear, war, jar etc), see http://jira.codehaus.org/browse/MSHARED-148 related/links section
Known non-thread safe libraries
Known thread safety problems have been fixed in the following library versions:
plexus-utils 2.0.5
maven-archiver 2.4.1
plexus-archiver 1.0
plexus-io 1.0
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. http://jira.codehaus.org/browse/MNG-2727
Mojo thread safety assertion checklist
Sometimes it can be hard to determine if a plugin and the underlying libraries are thread-safe, so when adding @threadSafe the following checklist can be used:
Check all static fields/variables in plugin/plugin code are not subject to threading problems.
Check any plexus components.xml; if the components defined are singletons they need to be threadsafe.
Check for presence of known tainted libraries.
This checklist qualifies for a "simple thread safety" review of a mojo.