I'm using a local artifactory to proxy the request, but the build and test phases are still a bit slow. It's not the actual compile and tests that are slow, it's the "warmup" of the maven2 framework. Any ideas?
-
2If you find a good answer out-of-band (f.ex. on other sites), it would be very appreciated if you posted them here as an answer. – Einar Oct 02 '08 at 13:29
-
I found [this article](http://zeroturnaround.com/rebellabs/your-maven-build-is-slow-speed-it-up/) helpful. Limiting internet access works well for me. – artronics May 01 '16 at 19:04
8 Answers
There are some possibilities to optimize some of the build tasks. For example the 'clean' task can be optimized from minutes to just milliseconds using simple trick - rename 'target' folder instead of delete.
To get details how to do it refer to Speed up Maven build.
-
-
2I tackled this issue for a while and took the time to write a blog post about it... hope it helps others! http://www.urbancat.org/2012/05/how-to-speed-maven-up.html – Nadav Jun 02 '12 at 15:21
-
1
I don't know what version of Maven you are using, I assume 2, but I will give what I use for Maven 1.x to speed up and make things build a tiny bit quicker.
These will fork the junit tests into a new process (also helps when you use environment variables in tests etc and gives the tests a little more memory.
-Dmaven.junit.fork=true
-Dmaven.junit.jvmargs=-Xmx512m
This forks the compilation which might speed things up for you
-Dmaven.compile.fork=true
I hope this can help a little, try it out.
Also refer to get more speed with your maven2 build.
-
I'm using maven2 but it's a nice link and I'll definitely try that patched version for my downloads. However the issue was more build and test startup times... – s3v1 Oct 02 '08 at 10:56
-
If you are using Maven3 ($ mvn -version
), you can also follow this guide. In my case, the results are:
Normal execution:
$ mvn clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:05 min
[INFO] Finished at: 2015-07-15T11:47:02+02:00
[INFO] Final Memory: 88M/384M
With Parallel Processing (4 threads):
$ mvn -T 4 clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:22 min (Wall Clock)
[INFO] Finished at: 2015-07-15T11:50:57+02:00
[INFO] Final Memory: 80M/533M
Parallel Processing (2 threads per core)
$ mvn -T 2C clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:12 min (Wall Clock)
[INFO] Finished at: 2015-07-15T12:00:29+02:00
[INFO] Final Memory: 87M/519M
[INFO] ------------------------------------------------------------------------
As we can see, the difference it's almost a minute, near 20-30% of speed improvement.

- 2,973
- 28
- 27
Adjust memory configurations to optimum for eg: add this line to mvn.bat set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=256m
Clean phase of mvn normally deletes target folder. Instead if we are renaming target folder the cleaning phase will be much faster.<quickClean>
-Dmaven.test.skip=true will skip the test execution.
Add -Denforcer.skip=true to mvn command line argument (This is enforcing versions of maven, jdk etc ,we can skip it after initial runs)
Disable non-critical operations during build phase: Analysis, javadoc generation, source packaging. This will save huge time.
Spawnig new process also helps in time improvement -Dmaven.junit.fork=true (fork the junit tests into a new process) -Dmaven.compile.fork=true (forks the compilation)
Hope it helps.

- 920
- 5
- 10
You can use -DskipTests=true
to skip unit tests. which would speed up builds
-
1
-
The CI robot will do all these when building, so they need to be there. – Thorbjørn Ravn Andersen Feb 07 '13 at 10:30
-
-o indicating offline mode helps as it does not look at remote updates for snapshots – Abs May 01 '15 at 07:20
I've found that parsing reactor projects is significantly slower than single-pom projects. If your build is reactor (multi-module) and your developers are not working on all modules at the same time, you can remove the parent POM and build them separately, resolving the dependencies using the local repo. The disadvantage is that you need to install or deploy a module in order for its dependents to see the changes.
Also, you might want to look at the new Maven 2.1 M1 which contains some significant speed improvements.
If none of these helps, post more details about your project configuration (modules structure and plugins), command line parameters and hardware config (memory and disk). Running Maven with -X might also show where is it taking its time.

- 3,293
- 3
- 31
- 46
-
it is indeed a reactor projct that I'm using. three small modules and a webprojekt. I tried that 2.1 build and it did seem a little faster. – s3v1 Oct 03 '08 at 10:23
I'd use locally installed Nexus.

- 22,316
- 18
- 72
- 99
-
Nexus is good too. I've used both nexus and artifactory, and they're both pretty fast. Nexus is a bit easier to configure IMO – s3v1 Dec 03 '09 at 13:28
-
Initially, you should get a finer analysis on your build times using something like this and identify the candidates that are taking the most time.
Are tests spinning up a H2 database per test? Is the download of external jar files taking the time? This will guide where to focus your investigation. Just applying go-fast flags don't usually work as they would have already been included by default, and you don't want to be sacrificing your tests with skip flags.

- 2,955
- 20
- 24