skip to content

When module-app depends on module-core in the same reactor, how does Maven resolve module-core's classes without you running mvn install first?

level: middleimportance: must knowfreq 55%

answer

  1. resolve from target/ not ~/.m2
  2. no mvn install needed
  3. core built first in session
  4. -pl app -am also-make
  5. single-module build loses reactor resolution

basics

~10 s

Within a single reactor build, Maven resolves a dependency module directly from its freshly built target/ output (or in-memory artifact) instead of the local ~/.m2 repository, so you don't need a separate mvn install.

solid answer

~40 s

Because the reactor builds core before app (topological order), core's output is already produced in the same session. Maven's intra-reactor resolution lets app use core's just-built artifact straight from core/target/ — typically the target/classes directory or the built JAR — without core having been installed into the local repository (~/.m2). This is why `mvn compile` or `mvn test` works on a fresh multi-module checkout with no prior `mvn install`. The phase you run matters: if app needs core's compiled classes for compilation, running at least `compile` on the reactor is enough; you don't need `install`. The local repo is only consulted for dependencies that are NOT part of the current reactor.

code

bash · 5 lines
bash
# Works on a fresh checkout with no prior install:
mvn test

# Build app and everything it depends on, in one reactor:
mvn -pl app -am test

go deeper

for a junior

Knows you can build a multi-module project without installing each module first.

for a middle

Explains that reactor deps resolve from target/ output during the same session, and which phase produces what.

for a senior

Knows the single-module-outside-reactor pitfall and uses -pl/-am to keep needed modules in the reactor.

for a principal

Reasons about CI caching, when install is genuinely required (cross-project publish), and how reactor resolution shapes incremental/partial build strategies.

## The problem this solves Normally a Maven dependency is resolved from a **repository** — first the **local repository** (`~/.m2/repository`), then remote repositories. An artifact lands in the local repo only when you run `mvn install`. So naively you'd think: to build `app` which depends on `core`, you must first `mvn install` core. That would be painful in a multi-module project. ## Intra-reactor resolution The reactor avoids this. When a module's dependency is **another module in the same reactor build**, Maven resolves it from the **module's own build output in `target/`**, not from `~/.m2`. Concretely: - Maven knows the GAV of every reactor module up front (it reads all the POMs before building). - For an inter-module dependency, it substitutes a reference to that module's **output directory / freshly built artifact** in the current session. - Depending on the phase reached, this is `core/target/classes` (for compile-time class access) or the built `core/target/core-1.0.jar`. Because topological ordering guarantees core is built before app, that output already exists by the time app needs it. ## What this means in practice - `mvn test` on a clean clone of a multi-module project **just works** — no `mvn install` needed first. - You only need to run a phase high enough to produce what the consumer needs. To compile app you need core compiled (`compile` phase); you do **not** need `install` (which copies to `~/.m2`) nor `package` unless something specifically needs core's packaged JAR. - The local repo is still used for **external** dependencies (third-party libs) and for reactor modules only when you build a module **outside** the reactor (e.g. `cd app && mvn test` without the parent), in which case core must have been previously installed. ## Common pitfall If you `cd` into a single module and build it alone, you are no longer in the multi-module reactor, so intra-reactor resolution does not apply — Maven looks in `~/.m2` and fails unless core was installed. Use the parent build, or `-pl app -am` (also-make), to keep core in the reactor. ## Example ```bash # Fresh clone, never installed anything: mvn test # core builds first, app resolves core from core/target # Build only app but include what it needs: mvn -pl app -am test # -am also builds core into the same reactor ```

  • What goes wrong if you cd into app and run mvn test directly?
    You leave the reactor, so Maven resolves core from ~/.m2; if core was never installed there, the build fails. Use the parent build or -pl app -am.
  • Do you ever still need mvn install in multi-module projects?
    Yes — when another build outside this reactor (a different project, or a standalone single-module run) needs the artifact, or to publish to the shared local repo. Within one reactor session it isn't required.

saying these in an interview costs you the question

  • Claiming you must mvn install every module before building dependents in the same reactor
  • Saying intra-reactor deps come from ~/.m2
  • Confusing -am (also-make) with -amd (also-make-dependents)

context

resolving links…