Maven interview questions often test whether you can connect build lifecycle concepts to real project configuration and troubleshooting. This guide is aimed at DevOps engineers and Java build owners who want concise, technically grounded answers they can explain clearly in interviews.
Originally published on 2010-03-11; fully revised and updated.

What interviewers usually expect you to know
- The difference between pom.xml and settings.xml and when to use each.
- How Maven lifecycle phases trigger plugin goals.
- How dependencies are resolved across local and remote repositories.
- How to debug build failures with Maven CLI flags.
- How Maven compares with Ant in standardization vs flexibility discussions.
pom.xml vs settings.xml: scope and best practice
The original FAQ got this core point right: keep project-wide, shareable configuration in pom.xml, and keep user- or machine-specific configuration in settings.xml.
| File | Scope | Typical content | Avoid putting here |
|---|---|---|---|
| pom.xml | Project and team | Dependencies, plugins, build lifecycle config, module structure | Developer-specific credentials, local proxy quirks |
| settings.xml | User or CI agent | Mirrors, repository credentials, proxy, local repository path | Business logic of the build, project dependencies |
<settings>
<mirrors>
<mirror>
<id>corp-mirror</id>
<url>https://repo.example.com/maven2</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>Code language: HTML, XML (xml)
Maven build and dependency resolution workflow
A strong interview answer connects lifecycle execution and repository behavior in one flow.
flowchart TD
A[Run mvn verify] --> B[Read project pom]
B --> C[Apply user settings]
C --> D[Resolve dependencies from local repository]
D --> E{Artifact already local}
E -- yes --> F[Use local copy]
E -- no --> G[Download from remote repository]
G --> H[Cache artifact locally]
F --> I[Execute lifecycle phases]
H --> I
I --> J[compile]
J --> K[test]
K --> L[package]
Repository types you should explain clearly
The source content used Maven 2-era terms, but this model is still useful in interviews.
| Repository type | Where it lives | Primary use |
|---|---|---|
| Local repository | Developer machine or CI worker | Cache artifacts for fast repeat builds |
| Private remote repository | Organization-managed server | Internal artifacts, policy control, faster enterprise builds |
| Public remote repository | Internet-hosted repository | Third-party open-source dependencies |
Practical configuration snippets interviewers often ask about
Use current date in build metadata
The original post points to the buildnumber plugin for timestamps during the validate phase.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-buildnumber-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<format>{0,date,yyyy-MM-dd HH:mm:ss}</format>
<items>
<item>timestamp</item>
</items>
<doCheck>false</doCheck>
<doUpdate>false</doUpdate>
</configuration>
</execution>
</executions>
</plugin>Code language: HTML, XML (xml)
Compile for a chosen JVM and exclude selected sources
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<excludes>
<exclude>**/NotNeeded*.java</exclude>
</excludes>
</configuration>
</plugin>Code language: HTML, XML (xml)
Set JAR output directory and Main-Class manifest entry
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<outputDirectory>${project.build.directory}/custom</outputDirectory>
<archive>
<manifest>
<mainClass>com.mycompany.app.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>Code language: HTML, XML (xml)
Run assembly plugin with multiple executions
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>bin</id>
<phase>install</phase>
<goals><goal>assembly</goal></goals>
<configuration>
<descriptors>
<descriptor>src/main/descriptors/bin.xml</descriptor>
</descriptors>
<finalName>${project.build.finalName}-bin</finalName>
</configuration>
</execution>
<execution>
<id>src</id>
<phase>install</phase>
<goals><goal>assembly</goal></goals>
<configuration>
<descriptors>
<descriptor>src/main/descriptors/src.xml</descriptor>
</descriptors>
<finalName>${project.build.finalName}-src</finalName>
</configuration>
</execution>
</executions>
</plugin>Code language: HTML, XML (xml)
Pass custom values from CLI and install third-party JARs
mvn -Dexpression.name=value install
mvn install:install-file \
-Dfile=/path/to/library.jar \
-DgroupId=com.example \
-DartifactId=example-lib \
-Dversion=1.0.0 \
-Dpackaging=jar \
-DgeneratePom=trueCode language: JavaScript (javascript)
Command comparison for troubleshooting
| Command | Best use case | Interview-ready explanation |
|---|---|---|
| mvn -X | Deep debug logging | Shows verbose build, plugin, and dependency resolution details. |
| mvn -e | Exception diagnosis | Prints full stack traces for build errors. |
| mvn –help | Option discovery | Lists CLI flags and usage quickly. |
| mvn assembly:assembly | Legacy equivalent for distribution-style packaging | Common answer when asked about Maven 1 style dist behavior. |
Maven vs Ant: concise comparison for interviews
| Aspect | Maven | Ant |
|---|---|---|
| Model | Convention-driven lifecycle and standardized structure | Task-oriented scripting toolbox |
| Flexibility | High, but within lifecycle conventions | Very high, fully custom workflow |
| Team consistency | Strong by default | Depends on script discipline |
| Typical interview framing | Best for repeatable project standards and dependency management | Best for highly customized build logic |
Source attribution and preserved links
Reference link preserved from the original post: http://www.javabeat.net. Original article URL: https://www.devopsschool.com/blog/maven-interview-questions-answers/.
Also preserved from the original page: YouTube API-key setup video link (https://www.youtube.com/watch?v=ZCfrNvu6nMc).
Common pitfalls
- Putting machine-specific settings (credentials, mirrors, proxy) into pom.xml.
- Running the same plugin execution multiple times without unique execution id values.
- Assuming compiled tests always run; execution depends on Surefire configuration and test filters.
- Treating sibling profiles as inheritable; profile merging behavior is more limited than many assume.
- Relying on very old Maven 2-era plugin behavior without checking current plugin documentation.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals