pom.xml Plugins Section
Fast recall
Quick revision
Core answer
build/plugins section declares and configures plugins used by this build. Plugin goals do work at lifecycle phases—for example, Compiler compiles sources, Surefire runs unit tests, Failsafe supports integration-test/verify, and the Spring Boot plugin can repackage an archive. pluginManagement supplies defaults but does not run a plugin unless it is otherwise declared or inherited into the active build.Understanding of Maven's plugin architecture and recognition of the common plugins in Spring Boot projects — plugins are how Maven becomes extensible
Not realizing that spring-boot-maven-plugin is what makes your JAR executable — without it you get a regular JAR that can't be run with java -jar
Explain Maven's lifecycle model and how plugins bind their goals to lifecycle phases — this is the mechanism that makes mvn install execute a sequence of plugin goals
Interview-ready guide
Interview answer
The build plugins section is where you configure Maven plugins that extend the build process.
Maven itself is really just a plugin execution framework — all the actual work like compiling code and running tests is done by plugins. Maven has a build lifecycle with phases like compile, test, and package. Plugins define goals that bind to these phases.
When you run mvn package, Maven executes all plugin goals bound to phases up through package. The common plugin in Spring Boot projects is the spring-boot-maven-plugin. This is what creates the executable JAR with nested runtime dependencies.
Without it, Maven produces a thin JAR that only contains your compiled classes, and you a plain JAR needs an appropriate manifest and external classpath rather than Boot's executable archive layout. The Spring Boot plugin runs its repackage goal during the package phase and creates that fat JAR with the special Spring Boot launcher. Another key plugin is maven-compiler-plugin, which compiles your Java source files.
version property you set, so you usually don't need to configure it yourself. The maven-surefire-plugin runs your unit tests during the test phase. It automatically finds test classes following certain naming patterns like ending with Test.
One mistake freshers make is not including the spring-boot-maven-plugin, then wondering why their JAR doesn't work. Another is adding unnecessary plugin configuration when the parent POM already handles it. The parent manages plugin versions just like dependency versions, so you shouldn't specify versions unless you have a specific reason to override.
pom.xml Plugins Section
Direct Answer
The build/plugins section declares and configures plugins used by this build. Plugin goals do work at lifecycle phases—for example, Compiler compiles sources, Surefire runs unit tests, Failsafe supports integration-test/verify, and the Spring Boot plugin can repackage an archive. pluginManagement supplies defaults but does not run a plugin unless it is otherwise declared or inherited into the active build.
Code Example
<build>
<plugins>
<!-- Spring Boot plugin: creates executable JAR -->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<!-- Version inherited from parent -->
<configuration>
<excludes>
<exclude>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</exclude>
</excludes>
</configuration>
</plugin>
<!-- Compiler plugin: Java version and compiler args -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<release>${java.version}</release> <!-- Uses property -->
<compilerArgs>
<arg>-parameters</arg> <!-- Preserve parameter names -->
</compilerArgs>
</configuration>
</plugin>
<!-- Surefire plugin: test execution configuration -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Xmx1024m</argLine> <!-- Increase test heap size -->
</configuration>
</plugin>
</plugins>
</build>
Common Mistakes & Pitfalls
- Forgetting spring-boot-maven-plugin: Creating a Spring Boot project without this plugin results in a thin JAR that can't be executed with java -jar — the JAR lacks dependencies and the custom Spring Boot launcher.
- Configuring plugins unnecessarily: Adding explicit configuration for maven-compiler-plugin when spring-boot-starter-parent already configures it correctly through properties like java.version — this creates confusion about which configuration wins.
- Wrong plugin groupId: Copying plugin configurations from old tutorials that use wrong groupIds — for example, using org.springframework.boot for plugins that are actually Apache Maven plugins.
- Mixing plugin versions: Explicitly setting plugin versions that conflict with versions managed by spring-boot-starter-parent, causing unexpected build behavior or compatibility issues with Spring Boot features.
Check your understanding
Answer these without looking back at the article.
- What does spring-boot-maven-plugin do that the regular maven jar plugin doesn't?
- How do you run a specific Maven plugin goal?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.