THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
As of Maven 3, 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.
Experimental feature for 3.0!
The parallel build feature has been subject to extensive testing, but the maven ecosystem is diverse so there will be undiscovered issues. We recommend that users of the parallel build feature establish their own reference as to how well this works for their project, preferably starting with everyday builds as opposed to final production releases.
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 a little 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.
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, EJB, JAR, WAR etc), see http://jira.codehaus.org/browse/MSHARED-148 related/links section. EAR, EJB, JAR and WAR are fixed in latest version.
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
Thread safe plugins and libraries
- 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
- Maven GPG Plugin 1.1
- Maven Plugin Plugin 2.7
- Maven Remote Resources Plugin 1.2
- Maven Source Plugin 2.1.2
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.
You might want to pay special attention to static member variables of the subclasses of "java.text.Format" (NumeberFormat, DateFormat etc), most of which
are not threadsafe and cannot be shared as static variables. - Check any plexus components.xml; if the components defined are singletons they need to be threadsafe.
- Check for presence of known tainted libraries.
- Check thread safety of any other third party libraries. This last item can be a bit hard, but inquiries on mailing lists can get you a long way.
This checklist qualifies for a "simple thread safety" review of a mojo.
If you need to learn more about multithreading and the java memory model it is probably wise to start off with a book like "Java Concurrency In Practice" or similar.
If a mojo uses a known-non-threadsafe external dependency, you may want to do something like this:
public class MyMojo
extends AbstractMojo
{
private static final Object lock = new Object();
public void execute()
{
synchronized( lock)
{
// Main mojo code
}
}
}