skip to content

Walk me through binding a plugin goal to a custom phase using an <execution> block. What does each sub-element control?

level: middleimportance: must knowfreq 60%

answer

  1. execution = one binding
  2. id -> merge by id
  3. phase -> attach point (omit = default phase)
  4. goals -> what runs
  5. configuration scoped per-execution

basics

~10 s

Inside a plugin you add <executions><execution>, give it an <id>, name the <phase> to attach to, list the <goals>, and optionally a <configuration>. That tells Maven to run those goals during that phase.

solid answer

~40 s

You bind extra goals under `<build><plugins><plugin><executions>`. Each `<execution>` has: an `<id>` (unique label, useful to override or merge inherited executions), a `<phase>` (which lifecycle phase to attach to — omit it to use the goal's default phase if it has one), `<goals>` (one or more goals to run), and an optional `<configuration>` scoped to that execution. Multiple executions of the same plugin can bind different goals to different phases, each with its own config. Execution order within a phase follows plugin declaration order, then execution order. A classic example is running `failsafe:integration-test` at `integration-test` and `failsafe:verify` at `verify`. Knowing `<id>` matters because inherited executions merge by id — same id overrides/extends, different id adds a new one.

code

xml · 15 lines
xml
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>3.1.0</version>
  <executions>
    <execution>
      <id>stamp-version</id>
      <phase>prepare-package</phase>
      <goals><goal>run</goal></goals>
      <configuration>
        <target><echo>v=${project.version}</echo></target>
      </configuration>
    </execution>
  </executions>
</plugin>

go deeper

for a junior

Know the four parts: id, phase, goals, configuration, and that this attaches a goal to a phase.

for a middle

Explain default-phase fallback, per-execution configuration, and positional ordering.

for a senior

Use id-based merge semantics deliberately to override or disable inherited executions.

for a principal

Design a build-management parent with stable, well-named executions so child modules extend rather than fight the inherited bindings.

## The execution block To bind a goal yourself, declare the plugin under `<build><plugins>` and add an `<executions>` list. Each `<execution>` is one binding (or group of goals) with these parts: - **`<id>`** — a unique name for this execution. Defaults to `default`. Critical for inheritance: when a parent POM defines an execution and a child redeclares one with the **same id**, they **merge** (child overrides matching fields). A **different id** creates an additional execution. Use distinct ids to avoid accidental merges. - **`<phase>`** — the lifecycle phase to attach the goals to. If omitted, Maven uses the goal's **default phase** (many goals declare one via `@Mojo(defaultPhase=...)`). If the goal has no default phase and you omit `<phase>`, it won't run during a normal build. - **`<goals>`** — one or more `<goal>` entries to execute. - **`<configuration>`** — parameters scoped to this execution only (overrides the plugin-level `<configuration>` for these goals). ## Example: integration tests with Failsafe ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>3.2.5</version> <executions> <execution> <id>run-it</id> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> <!-- no <phase>: these goals have default phases integration-test -> integration-test, verify -> verify --> </execution> </executions> </plugin> ``` ## Example: explicit custom phase ```xml <execution> <id>generate-build-info</id> <phase>generate-resources</phase> <goals><goal>run</goal></goals> <configuration> <target><echo>Building ${project.version}</echo></target> </configuration> </execution> ``` ## Ordering rules Within a single phase, goals run in: (1) the order plugins appear in the POM, then (2) the order executions appear within a plugin. There is no `<priority>`; ordering is positional. Inherited (parent) executions generally run before child-declared ones of the same phase. ## Why id discipline matters If a build-management parent declares `<execution><id>default</id>...` and a child also uses `default`, the child silently overrides it. Naming each execution prevents surprising merges and makes the binding intent explicit.

  • What happens if you omit <phase> in an execution?
    Maven uses the goal's declared default phase. If the goal has no default phase, the goal will not run during a normal lifecycle build (only if invoked directly).
  • How does <id> affect inheritance from a parent POM?
    Executions merge by id: same id in child overrides/extends the parent's; a different id adds a new, separate execution.
  • How is execution order determined within a phase?
    By position: plugin declaration order, then execution order within the plugin. There is no priority attribute.

saying these in an interview costs you the question

  • Thinking <phase> is always mandatory (some goals have default phases)
  • Assuming you can reorder executions with a priority attribute
  • Reusing the same <id> across parent and child without realizing it merges/overrides
  • Putting execution-specific config at plugin level and expecting it to apply only to one goal

context

resolving links…