A 40-module reactor build failed at module 27. How do you restart without rebuilding the first 26, and what are the caveats of doing so?
answer
- -rf = resume-from
- Maven prints the hint
- skips already-built modules
- don't add clean
- won't rebuild upstream edits
basics
~10 sRe-run with -rf :failedModule (--resume-from). Maven starts the reactor at that module and continues to the end, skipping the modules that already succeeded.
solid answer
~50 sUse `-rf` / `--resume-from <selector>` with the module that failed (Maven even prints the exact command hint, e.g. `mvn <goals> -rf :module-27`). The reactor recomputes its ordered list but begins execution at that module and proceeds to the end, so the 26 already-built modules are skipped. Caveats: (1) it relies on the earlier modules' outputs — typically their artifacts must be in `target/` or the local repo, which they are if you ran `install` and didn't clean; if you add `clean`, you wipe them. (2) `-rf` resumes from a point in the *original order*; it doesn't re-verify upstream modules changed in the meantime. (3) It's a convenience for iterating on a failing module, not a substitute for a clean full build in CI. For a clean re-run of just the failed module and its dependents you'd instead use `-pl :module-27 -amd`.
code
bash · 4 lines# resume the failed reactor at the offending module
mvn install -rf :reporting
# or by path
mvn install --resume-from services/reportinggo deeper
Know -rf restarts a failed reactor build from a module so earlier ones are skipped.
Explain the reliance on prior outputs/install and why clean defeats it.
Decide between -rf for local iteration vs -pl/-amd for isolated, reproducible rebuilds.
Discourage -rf in CI in favor of clean reproducible builds; use it as a developer convenience only.
## The scenario A reactor builds modules in a fixed sorted order. If module 27 throws a compile/test failure, Maven aborts. Re-running the whole thing wastes the time spent on modules 1-26. ## -rf / --resume-from `-rf <selector>` tells the reactor: keep the same computed build order, but **start executing at this module**. Everything before it in the order is skipped; everything from it onward runs. ```bash # original mvn install # ... fails in :reporting (module 27) # Maven prints: 'After correcting the problems, you can resume the build with the command # mvn <goals> -rf :reporting' mvn install -rf :reporting ``` The selector forms are the same as `-pl`: path, `groupId:artifactId`, or `:artifactId`. ## Why it works (and when it doesn't) Modules 1-26 already produced their artifacts. If you ran `install`, their jars are in `~/.m2/repository`, so module 27 can resolve them even though they aren't rebuilt. If you only ran `package` (no install) and a later module needs an earlier sibling's jar, resolution can still work because the reactor would normally provide it — but since those modules are now skipped, the artifact must exist somewhere resolvable. In practice `-rf` is most reliable after an `install`-based run and without `clean`. ## Caveats / pitfalls - **Don't prepend `clean`**: `mvn clean install -rf :reporting` deletes target dirs across modules and can break the assumption that earlier outputs exist. - **Stale upstreams**: if you edited an early module before resuming, `-rf` will not rebuild it — your fix won't be picked up. Use `-pl ... -am` instead. - **Order, not subset**: `-rf` includes *all* modules from that point onward, which may be more than you want. To target just the failing module use `-pl`. ## -rf vs -pl :failing -amd - `-rf :reporting`: resume the original run from module 27 to the end (fast iteration). - `-pl :reporting -amd`: build only reporting and its dependents from scratch (cleaner, more isolated).
- Why is `mvn clean install -rf :failed` often a mistake?clean deletes the target directories of all modules; resuming then skips the earlier modules so their freshly-deleted outputs are never rebuilt, breaking resolution or producing stale results.
- After fixing a bug in an early module, can you safely use -rf to resume past it?No. -rf skips modules before the resume point, so your edited early module won't be rebuilt. Use -pl on that module with -am/-amd instead.
saying these in an interview costs you the question
- Combining clean with -rf and expecting earlier outputs to survive
- Believing -rf rebuilds upstream modules you changed
- Thinking -rf only builds the single named module (it builds to the end)