In a Maven multi-module build, what determines the order in which the reactor builds the modules?
answer
- topological sort
- dependency edges not <modules> order
- parent + plugins count as edges
- cycle => build fails
- reactor summary shows order
basics
~20 sMaven's reactor builds modules in dependency order, not in the order they are listed in <modules>. It looks at each module's <dependency> entries and builds a needed module before the one that depends on it.
solid answer
~40 sThe reactor (Maven's multi-module engine) computes a topological sort of the modules based on inter-module dependency edges. It scans every module's <dependency> declarations, plus parent/plugin references, finds which other reactor modules each one depends on, and orders the build so a dependency is always built before its consumer. The order in the aggregator POM's <modules> list is only a starting hint and a tiebreaker when modules are independent; it does NOT dictate build order. So if module-app depends on module-core, core builds first even if app is listed first. A cyclic dependency between modules makes the graph unsortable and Maven fails with a cycle error.
code
xml · 8 lines<project>
<packaging>pom</packaging>
<modules>
<module>app</module>
<module>core</module>
</modules>
</project>
<!-- If app depends on core, Maven builds core BEFORE app -->go deeper
Knows the reactor builds dependencies before dependents and that <modules> order isn't authoritative.
Can explain that edges come from <dependency>, <parent>, and plugins, and that the result is a topological sort.
Understands tiebreaking by declaration order, cycle failures, and how missing declared edges cause subtle ordering bugs.
Designs module graphs to stay acyclic and shallow, and treats explicit dependency declarations as the contract that keeps reactor ordering deterministic.
## What the reactor is The **reactor** is the part of Maven that handles a build spanning multiple modules. When you run `mvn` against an **aggregator POM** (a POM with `<packaging>pom</packaging>` and a `<modules>` block), Maven collects all listed modules into one build session, decides an order, and builds them in sequence. ## Build order = topological sort, not declaration order The single most important fact: **the order of `<module>` entries does NOT decide build order.** Maven builds a directed graph where an edge points from a module to each other reactor module it depends on, then performs a **topological sort** — every module is built only after all the modules it depends on are built. Maven derives the edges from: - `<dependency>` entries that reference another reactor module's GAV (groupId/artifactId/version) - The `<parent>` reference if the parent is also in the reactor - Plugins (and their dependencies) that are themselves reactor modules The `<modules>` list order is used only as a **stable tiebreaker** for modules that have no dependency relationship between them. ## Why this matters It means you can list modules in any convenient order (often alphabetical) and Maven still gets it right. It also means a missing `<dependency>` edge — e.g. relying on classpath leakage rather than a real declared dependency — can produce a wrong order or flaky builds. ## Cycles fail the build If module A depends on B and B depends on A (directly or transitively), the graph has a **cycle**, no valid topological order exists, and Maven aborts with an error like "The projects in the reactor contain a cyclic reference." ## Example ```xml <!-- aggregator pom.xml --> <project> <packaging>pom</packaging> <modules> <module>app</module> <!-- listed first --> <module>core</module> <!-- listed second --> </modules> </project> ``` If `app/pom.xml` declares a dependency on `core`, Maven still builds **core first, then app**, ignoring the listing order. ## Inspecting the order Run the build with `-X` (debug) or just read the reactor summary at the end of any multi-module build — Maven prints the modules in the exact order it built them.
- If I reorder the <modules> list, will the build order change?No — declaration order only breaks ties between independent modules; real build order comes from the dependency graph.
- What happens if two modules depend on each other?The graph has a cycle, no topological order exists, and Maven fails with a cyclic reference error. You must break the cycle, often by extracting shared code into a third module.
Like cooking a recipe: you don't chop onions in alphabetical order, you do prep steps in the order the later steps need them.
saying these in an interview costs you the question
- Saying modules build in the order they appear in <modules>
- Believing you must manually order modules so dependencies come first
- Thinking parent POM references don't affect ordering