Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Your Maven build is slow. Speed it up!

We often dream that things will run faster (perhaps you’re serving a jail sentence), or happen sooner than they do so they’re not as annoying. It’s particularly painful, when you have little or no control over the thing you’re waiting for. Time seems to stop and every second feels like an eternity. Multiply that by 10 add 5, divide by 2 and square it. You now have a measure of how annoying this can feel. An example of such an annoyance might be the build time of your project. Perhaps you use Maven as your a build tool of choice? Then you most probably know this feeling.

Apache Maven Logo

Well, the good thing is that you’re reading this post! In this, I’ll try to explain some of the most common reasons as to why Maven build is taking longer than it should and figure out how it can be improved. So, if you’re one of those people who counts the seconds in a slow Maven build, keep reading, this should help you. Or at least will it will line up your thoughts to help figure out how to improve it.

Here are some the solutions to the common reasons why your Maven build is slow.

1. Parallel builds in Maven

By default, Maven does not utilize the full power of your hardware. It builds all modules sequentially rather than in parallel. However, often your project setup does not require it to be sequential. Often you can command Maven to analyze your project including the dependency graph and build the project in parallel where possible. You can either specify the exact number of threads to use for building your project or use a portable version of the parameter and specify the number of thread in terms of CPUs available on the machine.

mvn -T 4 install -- will use 4 threads
mvn -T 1C install -- will use 1 thread per available CPU core

While it might happen that your project is not easy to build in parallel it’s worth trying, the speedup can be substantial. Using one thread per CPU core is a good default. Your development machine probably has spare computing power and speeding up the build is always useful.

2. Running Maven tests in parallel

An aspect of build which probably has the biggest impact on your build speed are the tests. The most common practice is to disable the tests when you’re just interested in building your artifacts, but we cannot recommend such a non-conventional engineering practice.

If you really do intend to skip your test goals (Are you sure? Are you sure you’re sure?) during your Maven build, then the most common property that the majority plugins respect is: -DskipTests=true

However, you can achieve faster build times without damaging your feedback loop that much. The answer is running tests in parallel. The parallelization technique that we just discussed works on the module level. If you’re using an established plugin for running tests, let’s say, Surefire, you can also configure it for parallel execution within the module.

Running tests in parallel might lead to unwanted side-effects, especially if they are tangled together and expect to be executed in a certain order. However, that’s another story altogether and you should totally try it to see if it works for you and by how much it speeds up your build. You can always figure out the failures later.

3. Build necessary modules only

Let’s have a bet. I bet fifty RebelLabs dollars that when you build your project, the chances are you’re using the default command:

mvn clean install

Did I win? Thought so! While cleaning Maven is removing all the generated artifacts, all temporary files, except hopefully the configuration and the files checked in into the version control. It then generates fresh copies of those files again. It’s great for when you hit a weird caching issue or some obscure bug that you have but nobody else is able to reproduce. However, it will take extra precious seconds and CPU cycles to do what is essentially a needless job of recreating already existing files.

Instead what you most typically want to do is to build your project incrementally. Say you have a multi-module project with common core modules that rarely change and a web-interface that you’re currently working on. After changing the web-interface module try running a command like the following:

mvn install -pl $moduleName -am

First of all, we removed the implicit call to the clean phase. The project rarely requires cleaning, so we won’t want to do it all the time. Let’s take a look at the descriptions of the other options in the Maven command we just used:

  • -pl – makes Maven build only specified modules and not the whole project.
  • -am – makes Maven figure out what modules out target depends on and build them too.

The result of using these options together is the perfect combination of the flexibility and speed. We know what module we’re usually working on and if we have changed any dependencies, they will be renewed as well.

At the same time a large chunk of your project build will be skipped either because it’s still fresh and doesn’t require rebuilding or because it’s not a part of the target module and won’t play a role.

4. Limit internet access

You’ll like this one. If you sometimes feel like Maven is downloading the internet, know that you’re not alone! This is one of the most common complaints of any build system, npm, gradle, sbt. You name it, you’ll be surprised at how many libraries and transitive dependencies known to humanity will need to be downloaded at an arbitrary, and usually most inopportune time.

However, there’s a simple option you can enable that will make Maven work offline. You’ve probably guessed correctly, it’s the infamous offline key. When the offline mode is enabled, Maven won’t connect to any remote repositories when resolving dependencies. All the jar files in the local repository will still be available, so it won’t break your usual workflow.

So just append your mvn command with –offline and Maven won’t be tempted to check for a new snapshot of your favorite dependency and won’t make you wait for the network to respond.

If you don’t want to take it offline, but have a shady network connection, you can try setting:

-DdependencyLocationsEnabled=false to your MAVEN_OPTS variables. This addition will mean Maven will retain fewer outgoing connections throughout the build and maybe shave a few seconds off your build as well.

5. Speeding up Java startup

The last bit that I want to share with you today doesn’t come from my experience, but some research. Maven is a Java program, so it will of course run on the JVM. This in turn can be tuned for a much faster startup.

To make the JVM start a bit faster (safe in the knowledge we’re not dealing with a long-running application server process that has to be optimized for a faster execution later on), we can recommend the following two options for your Maven process:

-XX:+TieredCompilation -XX:TieredStopAtLevel=1

We just made your JVM perform the basic just-in-time compilation of the code only. It won’t try to gather a more precise profile and better optimize the execution of the code. The benefit of that is that the JIT doesn’t need that much information and the optimized code actually has a chance to kick in during a since build.

Note, that this advice is purely theoretical, I’d be happy if you could try it and mention whether your project build benefits from it.

Conclusion

In this post we’ve looked at several common reasons why a Maven build might be slow and could be annoying you each and every time it’s run.

In a nutshell, I think the default command for your build should be something along the lines of the following snippet:

MAVEN_OPTS= -XX:+TieredCompilation -XX:TieredStopAtLevel=1
mvn -T 1C install -pl $moduleName -am —offline

It will deny Maven its annoying right to download the internet, build only the necessary modules and their dependencies, while fine-tuning the JVM into faster shorter running programs, and won’t relentlessly clean the whole project again and again. You’re welcome.

I bet you’ve been waiting for me to say this next bit, so wait no longer! If you have an opportunity, consider trying out another build tool. For example Gradle is said to be more intelligent with greater “optimizations” as built-in defaults. The Virtual JUG recently hosted a great session of Gradle with Andres Almiray where these points were discussed, check it out!

PS. There might be a way to skip the build phase of your Java project completely. Check out JRebel, a revolutionary tool which reloads your code changes instantly without building your project at all!. It will make your development cycle faster by skipping your build, redeploy and restart stages. Your development experience will become more enjoyable and you will be a happier and more productive developer.


Read next:

  • Oleg Šelajev

    As Alex Blewitt correctly mentions in this tweet: https://twitter.com/alblue/status/631022349576486912

    If you don’t need the artifact in your local repository, but just want to run it, then use ‘package’ instead of the ‘install’ goal.

  • Paris Apostolopoulos

    Hello I think you should definitely take a look on the work Jason Vanzyl and his team, have put on the takari.io maven extention! its free, its well documenta and IMHO I think it should become at some point part of the main distribution.

    http://takari.io/

    It is an alternative build life-cycle and reactor, that manages to speed the overall build time in different ways and aspects!

  • Oleg Šelajev

    It sounds really interesting, I have to look at it! Thanks for mentioning it. I can see how the differences in the life-cycle and reactor can be a source of additional complexity for the teams, but it might also be quite manageable.

  • Paris Apostolopoulos

    I have introduced it to a real project for more than 1,5 years now, no problems with the traditional reactor /lifecycle they are compatible. At the time being, the jar packaging is optimized but they are planning on working for war /ear (if it is your case). We saw a great improvement, and with less configuration comparing to the post :).

    Give it a spin, it is worth your time really.

  • marcobehler

    Also check out these two blog entries (even though they are not entirely Maven specific, but Build/CI specific in general)

    http://www.marcobehler.com/2014/05/10/4-simple-ways-to-reduce-your-ci-build-cycle/

    and

    http://www.marcobehler.com/2014/05/19/speed-up-that-build-now-part-1-ramdisk-and-filesystem-2/

  • Oleg Šelajev

    I’d love to hear more stories about using this advice.

    https://twitter.com/planetsizebrain/status/633022097686720512

  • Did some testing with my open source project (isis.apache.org), this on an i7-4500U (2 core and 4 logical processors)

    144 secs: mvn clean install -o
    124 secs: mvn clean install -o -T 1C # this uses all 4 logical processors
    94 secs: mvn clean install -o -T1C with the MAVEN_OPTS

    So the MAVEN_OPTS provide a significant improvement. Avoiding doing the “clean” also (as expected) provides benefits:

    86 secs: mvn install -o -T 1C
    61 secs: mvn install -o -T 1C with the MAVEN_OPTS

    So thanks for this post, I’ll be updating our notes on how to build our framework from the cmd line..

  • Oleg Šelajev

    That’s great! Thank you for sharing the results with me.

  • Also you can -Dmaven.test.skip property to skip compiling the tests. Becouse -DskipTests only not RUNS them.
    https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html

  • From this two articles useful only idea to make build or RAM disk. Maybe it worst to be added to the article.

  • I found interesting tool to help profile maven build
    https://blog.sebastian-daschner.com/entries/analyze_maven_build_time
    https://github.com/timgifford/maven-buildtime-extension

    Could ypu please review it and add to the article if it helpful?
    Thanks

  • OG

    Do you know how can we obtain a speedup when packaging a jar with dependencies ?Thanks.

  • Václav Košař

    Maven extension gitflow-incremental-builder may be your friend. If you have multi-module maven project and you need to build or test only modules containing changes between two branches e.g. develop is usually stable and feature branches are not.
    See https://github.com/vackosar/gitflow-incremental-builder

  • John

    Check it out. they’re giving free instagram followers in a few seconds. been using this for followers

  • Vicente Rossello

    Yo can set the properties in the files maven.config and jvm.config in a .mvn folder, which is very convenient so everyone uses the same settings