skip to content

How would you profile a slow Maven build to find where the time goes, especially in dependency downloads?

level: middleimportance: should knowfreq 30%

answer

  1. profile first (build-profiler extension)
  2. -X / -e for resolution logs
  3. local Nexus/Artifactory mirror in settings.xml
  4. go-offline then -o
  5. tune SNAPSHOT updatePolicy / -nsu

basics

~10 s

Use a profiling extension like maven-profiler or -Dmaven.profiler style timing, and check -X (debug) logs to see per-plugin/goal durations. For downloads, watch resolution logs, point at a fast mirror/Nexus, and pre-cache with dependency:go-offline.

solid answer

~40 s

First measure, don't guess. The Takari/Maven build profiler extension prints a per-phase, per-plugin-goal timing breakdown so you can see whether time is in compilation, tests, or a specific plugin. `-X` (debug) and `-e` give detailed logs including artifact resolution. For downloads specifically: a cold `~/.m2` and a slow or distant remote repo dominate the first build — fix it by configuring a nearby mirror/proxy (Nexus/Artifactory) in `settings.xml`, enabling parallel resolution, and priming the cache (`dependency:go-offline`) or building offline (`-o`) afterward. Reduce repeated SNAPSHOT checks via update policy. Once profiled, the usual levers are: parallel reactor (`-T`), mvnd for warm JVM, the build-cache extension for unchanged modules, and trimming heavy/redundant plugin executions. The discipline is to profile, target the biggest contributor, then re-measure.

code

xml · 8 lines
xml
<!-- settings.xml -->
<mirrors>
  <mirror>
    <id>nexus</id>
    <mirrorOf>*</mirrorOf>
    <url>https://nexus.internal/repository/maven-public/</url>
  </mirror>
</mirrors>

go deeper

for a junior

Knows to look at logs and that a local mirror and offline mode help.

for a middle

Uses a profiler extension and -X to attribute time to phases/goals and addresses downloads.

for a senior

Picks the correct lever (mirror vs -T vs cache vs test split) from measured bottlenecks and re-measures.

for a principal

Stands up org-wide repository proxies, SNAPSHOT policies, and build-performance standards/dashboards.

## Step 1 — measure before optimizing Guessing wastes effort. Add a **build profiler extension** (commonly the Takari/Maven build-time profiler) that emits a breakdown of how long each *phase* and each *plugin goal* took. That tells you whether the cost is compilation, testing (Surefire/Failsafe), a code-gen plugin, or artifact resolution. Useful flags: - `-X` (`--debug`): full debug logging, including each artifact download and where it resolved from. - `-e` (`--errors`): stack traces for failures. ## Step 2 — diagnose downloads The first build on a fresh machine downloads everything; a slow or distant **remote repository** makes that painful. Look in the logs for `Downloading from …` lines and their durations. Fixes: - **Mirror/proxy:** run a local Nexus/Artifactory and route all of Central through it via a `<mirror>` in `settings.xml`. Cached locally, downloads become LAN-speed. - **Parallel resolution:** modern Maven resolves artifacts concurrently; ensure you're not forcing serial. - **Prime then go offline:** `mvn dependency:go-offline` downloads all deps/plugins up front; later builds run `-o`. - **SNAPSHOT update policy:** SNAPSHOTs trigger repeated remote checks. Tune `<updatePolicy>` (e.g. `daily`) or use `-o`/`-nsu` (`--no-snapshot-updates`) to skip them. ```xml <!-- settings.xml: route everything through a local Nexus mirror --> <mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>https://nexus.internal/repository/maven-public/</url> </mirror> </mirrors> ``` ## Step 3 — apply the right lever Once you know the bottleneck: - **Compile/parallelizable modules:** `-T 1C` parallel reactor. - **Frequent dev rebuilds:** `mvnd` (warm JVM). - **Unchanged modules:** `maven-build-cache-extension`. - **Slow tests:** parallelize Surefile/Failsafe forks or split slow integration tests. - **Redundant plugin executions:** remove/scope them. ## Step 4 — re-measure Profile again to confirm the change moved the needle and didn't just shift the bottleneck. Optimization is iterative.

  • Why does adding a local mirror often help download time more than any flag?
    Central is remote and shared; a local Nexus/Artifactory caches artifacts on your LAN, so after the first fetch every machine pulls at LAN speed and avoids internet latency and rate limits.
  • How do SNAPSHOT dependencies hurt build time and how do you mitigate it?
    SNAPSHOTs make Maven check the remote repo for newer versions on each build. Tune <updatePolicy> (e.g. daily), or run offline / with -nsu (--no-snapshot-updates) to skip the checks.

saying these in an interview costs you the question

  • Optimizing blindly (e.g. throwing -T at a test-bound or download-bound build) without profiling
  • Believing -X speeds up the build (it adds debug logging, it doesn't optimize)
  • Ignoring SNAPSHOT update checks as a recurring network cost

context

resolving links…