skip to content

Explain the -o (offline) option and the difference between --fail-fast and --fail-at-end in a reactor build.

level: juniorimportance: should knowfreq 45%

answer

  1. -o = local repo only, no network
  2. go-offline to prime cache
  3. -ff default = stop first failure
  4. -fae = build the rest, report all
  5. -fn = never fail exit code; downstream always SKIPPED

basics

~20 s

-o builds offline using only the local repository, with no network access (faster, deterministic, but fails if something is missing). --fail-fast (default) stops at the first failed module; --fail-at-end keeps building independent modules and reports all failures at the end.

solid answer

~40 s

`-o`/`--offline` tells Maven not to contact remote repositories at all — it resolves everything from `~/.m2/repository`. This avoids network latency and SNAPSHOT update checks, giving faster, reproducible builds, but it fails immediately if a needed artifact isn't already cached. For reactor failure handling: `-ff`/`--fail-fast` is the default and aborts the whole build the moment any module fails. `-fae`/`--fail-at-end` continues building modules that don't depend on the failed one, then lists every failure at the end — useful in CI to surface all broken modules in a single run. `-fn`/`--fail-never` never returns a failure exit code regardless of errors. Modules downstream of a failed module are skipped under all modes because their dependencies didn't build.

code

bash · 2 lines
bash
mvn dependency:go-offline   # prime the local cache first
mvn -o -fae clean install   # offline build, report all module failures

go deeper

for a junior

Knows -o is offline and the default stops at first failure.

for a middle

Distinguishes -ff/-fae/-fn behavior and that downstream modules are skipped.

for a senior

Uses go-offline to make -o reliable and picks fail-at-end for CI signal quality.

for a principal

Sets repository/offline strategy (mirrors, air-gapped builds) and CI failure-policy standards.

## Offline mode (-o / --offline) Maven normally consults *remote repositories* (Maven Central, your company Nexus/Artifactory) to download dependencies and plugins, and to check for newer SNAPSHOTs. `-o` forces it to use **only** the local repository (default `~/.m2/repository`). - **Pros:** no network round-trips, no SNAPSHOT update checks, deterministic and fast; works on a plane or an air-gapped box. - **Cons:** if any required artifact is not already in the local cache, the build fails with a resolution error. You typically prime the cache first with an online build (e.g. `mvn dependency:go-offline`). ```bash mvn -o clean install # use only cached artifacts mvn dependency:go-offline # pre-download everything so -o will work later ``` ## Reactor failure modes In a multi-module (reactor) build you choose what happens when a module fails: - **`-ff` / `--fail-fast` (DEFAULT):** stop the entire build at the first module failure. Fastest feedback for a single broken thing. - **`-fae` / `--fail-at-end`:** keep building every module that does **not** depend (directly or transitively) on a failed module, then print a summary of all failures and return a non-zero exit code. Great for CI where you want to see *all* broken modules in one pass. - **`-fn` / `--fail-never`:** build everything possible and **always** exit 0, even on failures. Used for reporting/aggregation jobs where you don't want the pipeline to stop. Under every mode, a module that depends on a failed module is **skipped** (marked SKIPPED) because its inputs couldn't be produced. ## How they combine `-o` is orthogonal to the fail mode — you can run `mvn -o -fae install`. Offline controls *resolution*; the fail flags control *reactor continuation*.

  • Why might an offline build fail even though a previous online build worked?
    Because a plugin or transitive dependency was never actually downloaded into ~/.m2 (e.g. a goal not previously run), so resolution fails with nothing to fall back to. Use dependency:go-offline to prime it.
  • When would you prefer --fail-at-end over the default?
    In CI, to discover every failing module in one run instead of fixing one, re-running, finding the next — it surfaces all independent failures together.

saying these in an interview costs you the question

  • Thinking --fail-at-end ignores failures (it still returns non-zero; only --fail-never exits 0)
  • Believing modules downstream of a failure still build under --fail-at-end (they're skipped)
  • Thinking -o speeds up by downloading in parallel (it skips the network entirely)

context

resolving links…