skip to content

Explain the difference between -am (--also-make) and -amd (--also-make-dependents), and when you'd reach for each.

level: middleimportance: must knowfreq 60%

answer

  1. am = upstream (needs)
  2. amd = downstream (dependents)
  3. the 'd' = dependents
  4. combinable -am -amd
  5. CI: changed -pl + -amd

basics

~20 s

-am adds the modules your selected modules depend ON (upstream), so the build can resolve them. -amd adds the modules that depend on your selected modules (downstream), so you can verify nothing breaks. Both are used with -pl.

solid answer

~40 s

Both flags expand the set chosen by `-pl`. `-am` / `--also-make` walks **upstream**: it adds every module your selected modules depend on, ensuring their dependencies are freshly built within the reactor rather than pulled from the local repo. Use it when you want to build a leaf module and its prerequisites from source. `-amd` / `--also-make-dependents` walks **downstream**: it adds every module that depends on your selection, so you can confirm a change in a low-level module doesn't break its consumers. Use it after editing a shared/core module to test the blast radius. They are independent and combinable: `-pl :core -am -amd` builds core, everything core needs, and everything that needs core. Mnemonic: `-am` = 'also make what I need', `-amd` = 'also make who needs me (dependents)'.

code

bash · 3 lines
bash
mvn install -pl :service -am    # service + core (upstream deps)
mvn verify  -pl :core    -amd   # core + service + web (dependents)
mvn verify  -pl :core    -am -amd  # both directions

go deeper

for a junior

Know -am brings in needed modules and -amd brings in modules that need yours; both pair with -pl.

for a middle

Articulate the upstream vs downstream graph direction and the 'cannot resolve sibling' problem -am solves.

for a senior

Choose flags per scenario (build-from-source vs blast-radius testing) and combine with -rf and -T for fast pipelines.

for a principal

Standardize the changed-module detection + -amd convention across CI for the org and reason about correctness vs build time trade-offs.

## Setup: the dependency direction In a graph `core -> service -> web` (web depends on service, service depends on core), 'upstream' of `service` is `core` (what it needs), and 'downstream' of `service` is `web` (who needs it). ## -am / --also-make (upstream) Given `-pl :service -am`, the reactor includes `service` **plus** `core` — the transitive set of modules `service` depends on. This guarantees those dependencies are built from current source and installed/available to the reactor, fixing the classic 'cannot resolve sibling' failure of bare `-pl`. ## -amd / --also-make-dependents (downstream) Given `-pl :core -amd`, the reactor includes `core` **plus** `service` and `web` — every module that (transitively) depends on `core`. This is your safety net: when you change a foundational module you build all consumers to catch breakage. ## Combining them ```bash # core + its upstreams + all its dependents mvn verify -pl :core -am -amd ``` This is handy when `core` itself depends on other modules and you also want to validate consumers. ## Practical CI pattern A common 'build only what changed' pipeline computes the changed module(s) from git diff and runs: ```bash mvn verify -pl <changed-modules> -amd ``` so it tests the changed modules and everything affected by them. Add `-am` if changed modules might need fresh upstreams. ## Key terms - **Upstream / dependency**: module(s) the target needs. - **Downstream / dependent**: module(s) that need the target. - **Transitive**: follows the chain, not just direct neighbors. ## Common mistake Reversing the two — expecting `-am` to test consumers. It does the opposite. Remember: `-am` pulls *in* prerequisites; the extra 'd' in `-amd` = **dependents** (consumers).

  • You changed a shared 'common' module. Which flag confirms you didn't break other modules, and why?
    -amd (--also-make-dependents): it adds every module that depends on common, so the build/tests run across all consumers to catch breakage.
  • Does -am pull dependencies from the local repo or build them from source?
    It includes them in the reactor and builds them from source, rather than relying on a previously installed artifact in ~/.m2.

saying these in an interview costs you the question

  • Saying -am builds dependents/consumers (it builds dependencies)
  • Saying -amd builds upstream prerequisites
  • Thinking the two flags are mutually exclusive

context

resolving links…