skip to content

Explain the <executions> element: what do id, phase, goals, and a per-execution <configuration> control?

level: middleimportance: must knowfreq 75%

answer

  1. id = merge/identity key
  2. phase = when it runs
  3. goals = which Mojo goals
  4. execution config overrides plugin-level
  5. <phase>none</phase> disables inherited execution

basics

~10 s

An <execution> binds a plugin's goal(s) to a lifecycle phase. <id> names it, <phase> says when it runs, <goals> lists which goals to run, and an execution-scoped <configuration> sets parameters only for that execution.

solid answer

~40 s

`<executions>` is how you wire a plugin goal into Maven's build lifecycle. Each `<execution>` has: an `<id>` (unique per plugin, used to identify, override, or merge the execution — defaults to `default`); a `<phase>` that binds the goal(s) to a lifecycle phase (e.g. `prepare-package`); a `<goals>` list of the Mojo goals to run; and an optional `<configuration>` that applies only to that execution. You can have multiple executions of the same plugin bound to different phases with different config — e.g. run `exec-maven-plugin` twice. If you omit `<phase>`, many goals have a default phase via their `@Mojo(defaultPhase=...)`; otherwise the execution only runs when invoked directly. The `<id>` is also the merge key: a child POM execution with the same id overrides/merges with the parent's, while a new id adds an execution.

code

xml · 10 lines
xml
<executions>
  <execution>
    <id>copy-resources</id>
    <phase>prepare-package</phase>
    <goals><goal>copy-resources</goal></goals>
    <configuration>
      <outputDirectory>${project.build.directory}/extra</outputDirectory>
    </configuration>
  </execution>
</executions>

go deeper

for a junior

Knows <execution> binds a goal to a phase with id/phase/goals.

for a middle

Can write multiple executions, scope config per execution, and order goals within a phase.

for a senior

Uses id as merge key to override/disable inherited executions (<phase>none</phase>) and reasons about phase ordering.

for a principal

Designs lifecycle bindings across a module hierarchy and governs reusable execution patterns in parent POMs.

## The lifecycle and binding Maven's default build **lifecycle** is an ordered list of **phases**: `validate → compile → test → package → verify → install → deploy` (plus sub-phases like `process-resources`, `generate-sources`, `prepare-package`). Running `mvn package` runs every phase up to and including `package`. Plugins do work by **binding goals to phases**; `<executions>` is the binding mechanism. ## Anatomy of an <execution> ```xml <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>3.2.0</version> <executions> <execution> <id>generate-build-info</id> <phase>generate-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>./scripts/buildinfo.sh</executable> </configuration> </execution> </executions> </plugin> ``` - **`<id>`** — a name unique within this plugin's executions. Defaults to `default-<goal>` for lifecycle-bound goals and `default` for manual ones. Crucially, the id is the **identity key for inheritance/merging**: same id ⇒ merge/override; different id ⇒ add a separate execution. - **`<phase>`** — the lifecycle phase the goal binds to. If omitted, the goal uses its Mojo's `defaultPhase`; if it has none, the execution runs only when the goal is invoked directly. - **`<goals>`** — one or more goals from this plugin to run during that phase. - **`<configuration>`** — execution-scoped parameters; they apply **only** to the goals in this execution, layered on top of (and overriding) any plugin-level configuration. ## Multiple executions You can declare several `<execution>` blocks for the same plugin, each with its own id, phase, goals, and config — e.g. run a code generator in `generate-sources` and a file copy in `prepare-package`. ## Disabling an inherited execution Because id is the merge key, you can neutralize a parent/super-POM execution by redeclaring the same id with `<phase>none</phase>` (or an empty/`<phase/>`), which unbinds it. ## Phase ordering within a phase If several goals bind to the same phase, they execute in the **order declared** in the POM (plugin order, then execution order), which matters when one step depends on another.

  • How do you turn OFF an execution that a parent POM defined?
    Redeclare an execution with the same <id> and set <phase>none</phase> (or empty phase). Since id is the merge key, this unbinds the inherited goal from any phase.
  • If two goals are bound to the same phase, what determines run order?
    Declaration order in the POM — plugins are processed in listed order, and within a plugin, executions run in the order written.
  • What happens if you omit <phase>?
    The goal binds to its Mojo's defaultPhase if it has one; otherwise it runs only when you invoke the goal directly on the command line.

saying these in an interview costs you the question

  • Thinking each plugin can only have one execution
  • Believing execution config is global to the plugin (it is scoped to that execution)
  • Not knowing id is the inheritance/merge key
  • Claiming you cannot disable an inherited execution

context

resolving links…