skip to content

What does requiresDependencyResolution on a Mojo do, and when would you need it?

level: seniorimportance: should knowfreq 35%

answer

  1. resolve deps before execute()
  2. ResolutionScope: COMPILE/RUNTIME/TEST/NONE
  3. needed for getArtifacts()/classpath
  4. collection = graph only, no download
  5. pick narrowest scope

basics

~20 s

It tells Maven to resolve the project's dependencies (for a given scope) before running the Mojo, so the Mojo can read the resolved artifacts/classpath. You need it whenever your goal inspects or uses the project's dependencies.

solid answer

~50 s

`@Mojo(requiresDependencyResolution = ResolutionScope.COMPILE)` (or TEST, RUNTIME, etc.) instructs Maven to resolve the project's dependency tree for that scope *before* invoking your goal. Without it, methods like `project.getCompileClasspathElements()` or `project.getArtifacts()` return empty/unresolved data, because Maven doesn't resolve dependencies unless a goal asks. Pick the narrowest scope you need: COMPILE for compile+provided, RUNTIME for compile+runtime, TEST for everything, COMPILE_PLUS_RUNTIME for both. There's also `requiresDependencyCollection` (cheaper — builds the dependency graph without downloading artifacts) for goals that only need the tree structure, not the files. Declaring resolution has a cost (it may trigger downloads), so don't request a wider scope than the goal actually uses. A goal that runs the app, builds a fat JAR, scans bytecode, or computes a classpath needs this; a goal that only touches source files or writes a report from the POM model does not.

code

java · 15 lines
java
@Mojo(name = "scan",
      requiresDependencyResolution = ResolutionScope.COMPILE,
      threadSafe = true)
public class ScanMojo extends AbstractMojo {
    @Parameter(defaultValue = "${project}", readonly = true)
    private MavenProject project;

    @Override
    public void execute() throws MojoExecutionException {
        // populated only because resolution was requested
        for (Artifact a : project.getArtifacts()) {
            getLog().info(a.getId());
        }
    }
}

go deeper

for a junior

Aware that some plugins need the project's dependencies and you must declare it.

for a middle

Knows the attribute and the scope enum, and that getArtifacts() is empty without it.

for a senior

Picks the narrowest scope, knows resolution vs. collection and the performance/correctness trade-off.

for a principal

Reasons about build performance and reliability at scale — minimizing resolution, avoiding goals that force unnecessary downloads.

## The problem it solves Maven does **not** resolve a project's dependencies just because a build runs — resolution (and the downloads it may trigger) happens only when a goal declares it needs them. If your Mojo calls something like `project.getArtifacts()` or `project.getCompileClasspathElements()` without declaring resolution, you get empty or unpopulated results. ## Declaring it ```java @Mojo(name = "scan", requiresDependencyResolution = ResolutionScope.COMPILE, threadSafe = true) public class ScanMojo extends AbstractMojo { ... } ``` ## ResolutionScope values - `COMPILE` — compile + provided + system dependencies. - `COMPILE_PLUS_RUNTIME` — adds runtime. - `RUNTIME` — compile + runtime (the deploy/exec classpath). - `RUNTIME_PLUS_SYSTEM` — runtime + system. - `TEST` — everything (the widest; what tests see). - `NONE` — default; nothing resolved. Choose the **narrowest** scope that satisfies the goal — wider scopes resolve (and possibly download) more artifacts. ## Resolution vs. collection - **`requiresDependencyResolution`** — resolves *and* makes the artifact files available (downloads if missing). Use when you need the actual JARs / a real classpath. - **`requiresDependencyCollection`** — builds the dependency *graph* (group:artifact:version tree) without fetching files. Cheaper; use when you only analyze the tree (e.g. a dependency-report or enforcer-style check). ## When you need it - Running or forking the application (exec-style goals) → RUNTIME or TEST. - Building shaded/uber JARs → RUNTIME. - Bytecode/classpath scanning, code generation that reads dependency classes → COMPILE or TEST. - Reports listing resolved versions → often COMPILE/TEST or just collection. Not needed for goals that only read the POM model, touch source files, or copy resources. ## Cost & correctness notes - Requesting it can slow the build (downloads) and may fail if a dependency is unresolvable — so don't over-request. - It runs during the goal's setup; by the time `execute()` is called, `project.getArtifacts()` reflects the requested scope.

  • What is the difference between requiresDependencyResolution and requiresDependencyCollection?
    Resolution makes the actual artifact files available (downloading if needed) — use it when you need the JARs/classpath. Collection only builds the dependency graph without fetching files — cheaper, for goals that just analyze the tree.
  • What happens if a Mojo reads project.getArtifacts() without declaring resolution?
    The collection is empty or unpopulated because Maven never resolved the dependencies for that goal; the Mojo silently sees no dependencies.

saying these in an interview costs you the question

  • Assuming dependencies are always resolved for every goal
  • Always requesting TEST scope 'to be safe' — it over-resolves and slows the build
  • Confusing resolution (files) with collection (graph)
  • Thinking it downloads at execute() time rather than before

context

resolving links…