What does the <configuration> block do inside a Maven plugin declaration, and how do you pass parameters to a plugin?
answer
- child elements = Mojo parameter names
- plugin-level vs execution-scoped
- type coercion (lists, maps)
- help:describe -Ddetail
- unknown element silently ignored
basics
~20 sThe <configuration> block sets a plugin's parameters in the pom.xml. Each child element name matches a plugin parameter (for example <source>17</source> for the compiler), and Maven injects those values into the plugin Mojo when it runs.
solid answer
~30 sA plugin's behavior is tuned through a `<configuration>` element placed inside its `<plugin>` declaration in `<build><plugins>`. The child element names map directly to the fields (parameters) of the plugin's Mojo classes — e.g. `maven-compiler-plugin` exposes `<source>`, `<target>`/`<release>`; `maven-surefire-plugin` exposes `<skipTests>`, `<includes>`. A `<configuration>` at the `<plugin>` level applies to every goal/execution of that plugin (plugin-level config), unless overridden inside a specific `<execution>` (execution-scoped). Values can use `${property}` references and System/env properties. You discover available parameters with `mvn help:describe -Dplugin=... -Ddetail`. Type coercion is automatic: strings, booleans, lists (`<includes><include>...`), and Maps are converted from XML to the Mojo field types.
code
xml · 11 lines<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.2.5</version>
<configuration>
<skipTests>false</skipTests>
<includes>
<include>**/*Test.java</include>
</includes>
</configuration>
</plugin>go deeper
Knows <configuration> sets plugin parameters and child names match parameter names.
Understands type coercion, lists/maps, property interpolation, and help:describe discovery.
Distinguishes plugin-level vs execution-scoped config and explains why typo'd elements silently do nothing.
Can teach Mojo parameter binding, user-property overrides, and sets team conventions for discoverable, documented plugin config.
## What a plugin is Maven does almost nothing on its own — every real action (compiling, testing, packaging a JAR, copying files) is performed by a **plugin**. A plugin is a JAR containing one or more **Mojos** ("Maven plain Old Java Objects"), and each Mojo implements a **goal** (e.g. `compiler:compile`). A goal is the smallest unit of work you can invoke. ## The <configuration> element A Mojo declares parameters as annotated Java fields. You set those parameters from the POM with a `<configuration>` block whose **child element names match the parameter names**: ```xml <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <configuration> <release>17</release> <showWarnings>true</showWarnings> <compilerArgs> <arg>-Xlint:all</arg> </compilerArgs> </configuration> </plugin> </plugins> </build> ``` Here `<release>` maps to the compiler Mojo's `release` parameter; `<compilerArgs>` is a list, so it has repeated child `<arg>` elements. ## Plugin-level vs execution-scoped configuration - A `<configuration>` placed **directly under `<plugin>`** is *plugin-level* — it applies to every goal/execution of that plugin (and to direct command-line invocations like `mvn surefire:test`). - A `<configuration>` placed **inside an `<execution>`** applies only to that execution's bound goal(s). ## How values are coerced Maven converts XML text into the Mojo field's Java type automatically: `String`, `int`/`boolean`, `File`, `List`/arrays (repeated child elements), `Map`/`Properties`, and even nested objects. Properties like `${project.build.directory}` or `${java.version}` are interpolated. ## Discovering parameters Use `mvn help:describe -Dplugin=org.apache.maven.plugins:maven-surefire-plugin -Ddetail` to list every goal and its parameters, defaults, and the user property that overrides each one (e.g. `skipTests` ← `-DskipTests`). ## Common pitfall The element names are **case-sensitive parameter names**, not arbitrary tags. A misspelled or unknown element is silently ignored (it just does nothing), which is a frequent source of "my config has no effect" confusion.
- Why might a value you put in <configuration> have no effect at all?Most likely the element name does not match a real Mojo parameter (typo or wrong name) — Maven ignores unknown configuration elements silently. Verify the exact parameter name with mvn help:describe -Ddetail.
- How is a List parameter expressed in XML?As a wrapper element containing repeated child elements, e.g. <includes><include>...</include></includes>. Maven maps the repeated children into the list/array field.
saying these in an interview costs you the question
- Thinking element names are arbitrary tags rather than exact parameter names
- Believing a wrong/typo'd element raises an error (it is silently ignored)
- Confusing plugin-level config with execution-scoped config