Maven Interview Questions and Answers

Interviewers want proof you can own the build, not only run mvn package. Expect questions across four layers:

Java backend and DevOps roles both ask Maven—often alongside Gradle comparison questions. Senior loops add multi-module reactors, enforcer rules, and debugging classpath conflicts with mvn dependency:tree.

Hands-on practice beats reading XML. A focused two-to-three week plan:

Break a build on purpose (wrong scope, duplicate JAR, missing exclusion) and fix it with mvn dependency:tree and mvn -e. Say answers aloud using the lifecycle phase names interviewers expect.

Recent loops emphasize supply chain and reproducibility as much as classic POM trivia:

Also expect skipTests vs maven.test.skip, Failsafe for integration tests, and enforcer plugin rules in corporate parent POMs.

Apache Maven is an open-source build and project-management tool from the Apache Software Foundation. It automates compiling, testing, packaging, and publishing Java projects using a declarative Project Object Model (pom.xml) rather than hand-written build scripts.

Maven is not just a compiler—it orchestrates the build: it resolves dependencies from repositories, runs plugins bound to lifecycle phases, and produces repeatable artifacts (JAR, WAR, EAR, etc.). Teams also use it for site generation, reporting, and release workflows.

A strong answer is:

Maven is an Apache build and project-management framework that uses a POM to compile, test, package, and publish Java projects with convention-based layout and centralized dependency resolution.

Maven combines a standard project layout, dependency management, and a plugin-driven lifecycle so teams spend less time wiring builds and more time shipping code.

Because every Maven project follows the same mental model, onboarding is faster: a developer who knows one Maven repo can navigate another without relearning the build.

A strong answer is:

Maven gives you standardized project structure, declarative dependency management, plugin-driven lifecycle phases, multi-module support, and integration with local and remote repositories.

Maven is broader than a compile tool—it manages the full software delivery pipeline around a Java project.

In practice, CI pipelines call Maven for the repeatable core—mvn verify or mvn deploy—while Maven handles dependency resolution and artifact naming consistently.

A strong answer is:

Maven manages build, testing, release, reporting, SCM hooks, documentation, and artifact distribution through a single POM-driven workflow.

Maven reduces build friction by replacing bespoke Ant scripts with shared conventions and declarative configuration.

Shared project structure — Every Maven project uses src/main/java, src/test/java, and pom.xml. Developers can jump between codebases without deciphering custom folder layouts.

Modular design — Multi-module reactors split large systems into manageable artifacts with one parent POM governing versions and plugin configuration.

Centralized dependency management — Dependencies are declared once in the POM; Maven downloads them from repositories instead of checking JARs into version control. Transitive dependencies resolve automatically.

Fewer non-coding decisions — Directory names, default phases, and plugin bindings come from conventions and the Super POM, so teams focus on application logic rather than reinventing build steps.

A strong answer is:

Maven standardizes project layout, supports modular multi-module builds, centralizes dependency resolution, and removes repetitive build configuration through conventions and inherited defaults.

Convention over configuration means sensible defaults replace boilerplate setup. Maven ships with opinions backed by years of Java practice—if you follow them, the build works with minimal XML.

Examples of Maven conventions:

You can override paths in the POM, but most projects never need to. Contrast this with Ant, where every copy-and-compile step is explicit. Maven assumes you want the standard layout unless you say otherwise.

A strong answer is:

Maven uses convention over configuration because it provides proven defaults for directory layout, lifecycle phases, and plugin bindings so developers configure only what differs from the norm.

A build tool like Maven automates the path from source code to deployable artifacts and keeps that path repeatable across machines and CI agents.

Maven also resolves third-party libraries, enforces dependency scopes, and runs quality checks in the verify phase—tasks that would be error-prone if done manually.

A strong answer is:

A build tool compiles source, runs tests, packages artifacts, generates documentation, and deploys releases—Maven handles all of this through lifecycle phases and plugins bound to a declarative POM.

Ant and Maven both build Java projects, but they represent different eras of build automation.

Ant remains useful for highly custom, non-standard builds. Maven dominates greenfield Java because dependency management and multi-module coordination are first-class.

A strong answer is:

Ant is a procedural task toolkit with no enforced structure; Maven is declarative, convention-based, with built-in lifecycles, dependency management, and reusable plugins.

MOJO stands for Maven plain Old Java Object. It is the Java class that implements a single executable goal inside a Maven plugin.

Each MOJO declares metadata—goal name, default lifecycle phase, required parameters—and Maven invokes it when you run a goal like compiler:compile or when a phase triggers a bound plugin.

Plugin (e.g., maven-compiler-plugin)
  └── MOJO: compile goal
  └── MOJO: testCompile goal

When you run mvn test, Maven reaches the test phase, which binds the Surefire plugin's MOJO to execute unit tests. Understanding MOJOs helps in interviews because "plugin" is the packaging unit and "goal/MOJO" is the unit of work.

A strong answer is:

A MOJO is a Maven plain Old Java Object—the Java class behind a plugin goal that Maven executes during a lifecycle phase or when you invoke the goal directly.

A Maven repository is a storage location for build artifacts, POM files, and metadata that Maven uses to resolve dependencies and publish releases.

When you declare a dependency in pom.xml, Maven looks up the artifact coordinates, downloads the JAR and its POM from a repository, caches them locally, and adds them to the compile or test classpath. Your own project's output is also stored as an artifact after mvn install.

Repositories are organized by coordinates: groupId/artifactId/version/ with the artifact file and checksums alongside.

A strong answer is:

A Maven repository stores artifacts, POMs, and metadata so Maven can download dependencies and publish built packages using coordinate-based directory layout.

Maven distinguishes three repository roles in the resolution chain:

Resolution order: Maven checks the local repository first. Missing artifacts are fetched from remote repositories configured in the POM or settings.xml (often via a mirror of Maven Central).

A strong answer is:

Maven uses a local cache on disk, Maven Central as the default public remote repository, and optional custom remote repos for private or mirrored artifacts.

The local repository is Maven's on-disk cache—typically ~/.m2/repository on Linux/macOS and %USERPROFILE%\.m2\repository on Windows.

Every dependency Maven downloads is stored here so subsequent builds skip network calls. Running mvn install also copies your project's artifact into the local repo, making it available as a dependency to other projects on the same machine via matching coordinates.

You can change the location in settings.xml:

<localRepository>/path/to/custom/repo</localRepository>

Clearing or corrupt entries in .m2 is a common troubleshooting step when checksum or snapshot resolution errors appear.

A strong answer is:

The local repository is Maven's per-machine cache—defaulting to ~/.m2/repository—where downloaded and installed artifacts are stored for reuse across projects.

Maven Central—hosted at repo.maven.apache.org—is the default public remote repository for open-source Java artifacts.

It holds millions of JARs and POMs indexed by groupId, artifactId, and version. When your POM declares a dependency without a <repository> override, Maven resolves it from Central (directly or through a corporate mirror).

Central is read-heavy infrastructure: builds worldwide pull artifacts from it or from mirrors. It is not a general-purpose file dump—artifacts are immutable once published under a release version.

A strong answer is:

Maven Central at repo.maven.apache.org is the default public remote repository where open-source artifacts are published and resolved by coordinate.

A remote repository is any repository accessed over the network (or a mounted file URL) that is not the local cache.

Remote repos are declared in the POM or, preferably for mirrors and credentials, in settings.xml. Maven fetches missing artifacts from remotes and stores copies in the local repository.

A strong answer is:

A remote repository is a network-accessible artifact store—Central, a corporate proxy, or a vendor repo—that Maven queries when an artifact is not in the local cache.

Binary JARs belong in artifact repositories, not in Git, CVS, or Subversion. Version control is optimized for text diffs and merge workflows—not large immutable binaries.

The POM declares coordinates; Maven downloads the exact artifact from a repository. That keeps source repos lean and builds reproducible.

A strong answer is:

Binaries bloat version control, slow checkouts, and lack transitive metadata—Maven repositories store artifacts once by coordinate while the POM in Git stays small and declarative.

No. Maven Central is not an open upload endpoint. Publishers now use the Central Publisher Portal: verify a namespace, meet Maven Central requirements (valid POM, sources, javadoc where applicable), and publish GPG-signed artifacts. The older Sonatype OSSRH workflow reached end of life in June 2025; existing publishers migrated to the portal.

For Maven-based publishing, use Sonatype's central-publishing-maven-plugin or the current Central Portal workflow—both replace the legacy OSSRH staging flow.

Corporate teams typically publish to an internal Nexus or Artifactory instead. Central is for vetted open-source releases consumed by the global Java ecosystem.

A strong answer is:

Anyone cannot upload to Maven Central—you register through the Central Publisher Portal, verify your namespace, sign artifacts with GPG, and meet Central requirements; private releases go to internal repository managers.

POM stands for Project Object Model. It is the fundamental unit of configuration in Maven—an XML file named pom.xml at the project root.

The POM describes project coordinates (groupId, artifactId, version), packaging type, dependencies, plugin configuration, modules, profiles, and build settings. Maven reads the POM (merged with parent and Super POM) to know what to compile, which dependencies to resolve, and which goals to run.

Multi-module projects use a parent POM with <modules> listing child projects; each child inherits shared dependency and plugin management.

A strong answer is:

The POM is Maven's Project Object Model—an XML descriptor that defines coordinates, dependencies, plugins, and build configuration for a project.

The Super POM is Maven's built-in default POM that every project inherits implicitly. Even a minimal pom.xml with only coordinates gets default plugin bindings, directory paths, and repository definitions from the Super POM.

View effective defaults with:

mvn help:effective-pom

The Super POM and Maven's default lifecycle provide inherited defaults such as standard directories (src/main/java, src/test/java), output location (target/), repositories, and default lifecycle behavior. Child POMs and parent POMs override or extend these values.

In real projects, pin plugin versions explicitly in pluginManagement to avoid surprises—effective plugin resolution also depends on lifecycle bindings and parent POMs, not only the Super POM.

A strong answer is:

The Super POM is Maven's built-in default configuration—all POMs inherit standard directories, lifecycle bindings, and repository defaults unless overridden; I still pin plugin versions in pluginManagement for reproducible builds.

Every Maven POM must include the root element and Maven model version plus the three coordinates that uniquely identify the artifact:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</project>

Optional but common: <packaging> (default jar), <name>, <description>, <dependencies>, and <build>.

A strong answer is:

A valid POM requires modelVersion, groupId, artifactId, and version—the coordinates Maven uses to identify and publish the artifact.

The default build lifecycle defines an ordered sequence of phases. Maven runs each phase and any earlier phases when you invoke a later one (e.g., mvn package runs through package inclusive).

Full default lifecycle includes: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy.

For interviews, focus on the main phases:

Plugins bind their goals to these phases—you rarely invoke phases individually.

A strong answer is:

The default lifecycle runs ordered phases from validate through deploy; interviews focus on compile, test, package, verify, install, and deploy as the core build pipeline.

Use the package lifecycle phase:

mvn package

This runs all phases up to and including package—compile, test, and then jar/war the output into target/. It does not install to the local repo (use mvn install) or publish remotely (use mvn deploy).

Common variants:

Note: the correct flag is -DskipTests or -Dmaven.test.skip=true, not mvn -package.

A strong answer is:

Run mvn package to compile, test, and create the distributable artifact in target/; add clean to wipe previous output first.

Maven identifies artifacts with coordinates in this format:

groupId:artifactId:version[:packaging][:classifier]

Examples:

• com.example:my-app:1.0.0 — default JAR
• com.example:my-app:1.0.0:war — WAR packaging
• com.example:my-app:1.0.0:jar:sources — sources classifier

In dependency declarations, packaging and classifier appear as XML elements rather than colon-separated segments.

A strong answer is:

Maven artifact coordinates follow groupId:artifactId:version with optional packaging and classifier—uniquely identifying every JAR, POM, or variant in a repository.

Maven defines three independent build lifecycles. Each lifecycle has its own sequence of phases; you invoke a phase and Maven runs that phase plus all earlier phases within the same lifecycle.

The default lifecycle (sometimes called build) is what interviews emphasize—validate, compile, test, package, install, deploy. clean and site are separate lifecycles you combine as needed: mvn clean install.

A strong answer is:

Maven has three lifecycles—clean, default, and site—each with its own phase sequence; default handles compile through deploy, clean removes old output, site generates documentation.

An archetype is a project template packaged as a Maven artifact. It generates a new project skeleton—directory layout, sample POM, and starter source—so teams start from a consistent structure.

Archetypes encode organizational standards: multi-module layout, chosen dependencies, plugin configuration, and package naming. The maven-archetype-plugin lists available templates (e.g., maven-archetype-quickstart) and prompts for groupId, artifactId, and package name.

Using archetypes reduces ramp-up time and enforces convention over configuration from day one.

A strong answer is:

A Maven archetype is a reusable project template that scaffolds directory structure, POM, and starter code so new projects match team conventions immediately.

Generate a new project interactively from an archetype:

mvn archetype:generate

Maven prompts for archetype selection (or filter by catalog), then groupId, artifactId, version, and package. For non-interactive CI or scripting, pass properties:

mvn archetype:generate \
  -DgroupId=com.example \
  -DartifactId=my-app \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DarchetypeVersion=1.5 \
  -DinteractiveMode=false

The plugin creates the project directory with standard src/main/java and src/test/java layout.

A strong answer is:

Use mvn archetype:generate to scaffold a new Maven project from a template, interactively or with -D properties for automation.

Maven itself is a plugin execution framework—nearly all build work is done by plugins binding goals (MOJOs) to lifecycle phases or invoked directly on the command line.

Configure plugin version and parameters in the POM <build><plugins> section. Pinning versions avoids surprises when the Super POM defaults change.

A strong answer is:

Maven plugins perform compile, test, package, clean, deploy, and reporting work by binding goals to lifecycle phases or running as standalone commands like mvn javadoc:javadoc.

Maven resolves plugin versions from the Super POM, parent POM, pluginManagement, or an explicit <version> on the plugin. To see what is actually in effect for your project, use the Help plugin's describe goal with the plugin prefix (not the full artifact ID):

mvn help:describe -Dplugin=compiler -Ddetail

Replace compiler with the prefix for any plugin (surefire, jar, install, etc.). Add -Dfull for even more detail.

The -Ddetail flag lists goals and lifecycle bindings—useful when debugging "which compiler plugin version is CI using?"

A strong answer is:

I run mvn help:describe -Dplugin=compiler -Ddetail to see the resolved plugin version and bindings, or mvn help:effective-pom when I need the full merged configuration.

Profiles let you vary build behavior (dependencies, properties, repositories, plugins) per environment or activation trigger.

Older Maven 2 builds used profiles.xml, but it was removed in Maven 3. Use POM or settings profiles instead.

Activation triggers:

• Command line: mvn -Pdev,integration-test
• Properties: -Denv=prod matching <property><name>env</name><value>prod</value></property>
• JDK version, OS family, or file presence

A strong answer is:

Project profiles live in pom.xml; user profiles in ~/.m2/settings.xml; global profiles in $MAVEN_HOME/conf/settings.xml. profiles.xml was removed in Maven 3—I use POM or settings profiles with -P or property activation.

Maven reads two settings.xml locations and merges them (user settings override global defaults):

On Windows, ~/.m2 resolves to C:\Users\<username>\.m2\.

Related files in ~/.m2/:

Use mvn help:effective-settings to see the merged result.

A strong answer is:

Global settings sit in $MAVEN_HOME/conf/settings.xml; per-user overrides in ~/.m2/settings.xml. User settings win on conflict—I verify with mvn help:effective-settings.

settings.xml configures Maven runtime behavior—not project structure (that belongs in pom.xml).

Example mirror (common in enterprises):

<mirrors>
  <mirror>
    <id>corp-nexus</id>
    <mirrorOf>central</mirrorOf>
    <url>https://nexus.example.com/repository/maven-central</url>
  </mirror>
</mirrors>

A strong answer is:

Key settings elements are localRepository, mirrors, servers, proxies, profiles, and activeProfiles—mirrors and server credentials are what I check first when CI cannot reach Central.

Run:

mvn -version

(or mvn -v or mvn --version)

Sample output:

Apache Maven 3.9.x
Maven home: /opt/maven
Java version: 21.0.2, vendor: Eclipse Adoptium
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.8.0", arch: "amd64"

This confirms Maven version, Maven home, and the JDK Maven will use—critical when debugging "wrong Java" build failures.

A strong answer is:

mvn -version reports Maven version, Maven home, and the Java runtime in use—I use it before blaming plugin or compiler errors on the wrong JDK.

Quick check — open Command Prompt or PowerShell:

mvn -version

If Maven is on PATH, you see version, Maven home, and Java details.

If the command is not found:

Alternative on a Wrapper project:

.\mvnw.cmd -version

Wrapper projects do not require a global Maven install.

A strong answer is:

I run mvn -version in cmd or PowerShell; if it fails I check MAVEN_HOME\bin on PATH and that Java is installed. On Wrapper projects I use mvnw.cmd instead.

An artifact is a file published to or resolved from a Maven repository—most often a JAR, but also WAR, EAR, ZIP, or a POM.

Coordinates uniquely identify an artifact:

groupId:artifactId:version[:packaging][:classifier]

Example: org.apache.commons:commons-lang3:3.14.0:jar

When you declare a <dependency>, you reference an artifact. When mvn package runs, Maven produces artifacts (e.g., target/myapp-1.0.0.jar) and mvn install copies them to the local repository.

A strong answer is:

A Maven artifact is a deployable file—usually a JAR—identified by GAV coordinates. Dependencies reference artifacts; the build produces and installs artifacts to the local or remote repository.

After mvn compile (or any phase that compiles main sources), compiled .class files land in:

${project.basedir}/target/classes/

Related output directories:

The path is driven by ${project.build.outputDirectory} (default target/classes). Custom layouts require explicit POM configuration—see question 50.

A strong answer is:

Main compiled classes go to target/classes/; test classes go to target/test-classes/. mvn clean wipes the whole target/ folder.

Maven's convention over configuration defaults:

Other conventional roots:

• src/main/webapp — WAR projects
• src/site — Maven site documentation

These defaults come from the Super POM. Override only when you have a legacy layout—and prefer migrating to standard directories when possible.

A strong answer is:

Defaults are src/main/java, src/test/java, and target/ for build output. I only override sourceDirectory or use build-helper-maven-plugin when legacy code cannot move.

The jar:jar goal (from maven-jar-plugin, bound to the package phase by default) creates a JAR from already-compiled classes.

Output:

target/${project.build.finalName}.jar

Default finalName is ${project.artifactId}-${project.version} → e.g. myapp-1.0.0.jar.

Run explicitly: mvn jar:jar — or simply mvn package, which runs jar:jar automatically for packaging=jar projects.

A strong answer is:

jar:jar packages compiled classes from target/classes/ into target/<artifactId>-<version>.jar during the package phase—it does not recompile sources.

Dependency scope controls classpath visibility and whether the dependency is propagated transitively.

provided scope: Provided dependencies are generally not included in the runtime classpath of downstream consumers—the practical interview answer, even though Maven's transitivity rules are more nuanced by dependency path.

import scope does not add a dependency—it merges version constraints from a BOM POM into dependencyManagement. Used heavily with Spring Boot and platform BOMs.

Verify effective scopes on the classpath with:

mvn dependency:tree -Dverbose

A strong answer is:

Six scopes: compile, provided, runtime, test, system, and import. Compile is default and transitive; provided and test are not on the runtime classpath; import is BOM-only in dependencyManagement—I confirm conflicts with mvn dependency:tree.

Use <exclusions> inside a direct <dependency> to block a transitive artifact from entering your classpath.

<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>library-a</artifactId>
    <version>2.0.0</version>
    <exclusions>
      <exclusion>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
</dependencies>

Verify the exclusion worked:

mvn dependency:tree | grep slf4j

For duplicate version conflicts, also consider maven-enforcer-plugin with dependencyConvergence or requireUpperBoundDeps.

A strong answer is:

I add <exclusions> under the direct dependency that pulls the unwanted transitive JAR, then confirm with mvn dependency:tree. For recurring conflicts I use enforcer rules or BOM alignment.

Maven resolves artifacts in a defined order:

1. Local repository (~/.m2/repository by default) — if the exact GAV exists, download is skipped
2. Remote repositories — declared in pom.xml, parent POM, or settings.xml mirrors
3. Download and cache — artifact is stored locally for reuse

Resolution steps (simplified):

pom.xml dependency (GAV)
    → merge dependencyManagement / BOM imports
    → apply exclusions and optional flags
    → resolve transitive graph
    → check local repo
    → fetch missing artifacts from remote(s)
    → store under ~/.m2/repository/<groupId path>/<artifactId>/<version>/

Mirrors in settings.xml can redirect all Central traffic to an internal proxy. SNAPSHOT artifacts re-resolve on a TTL (default: daily check for updates).

When multiple versions of the same artifact are reachable, Maven applies dependency mediation—commonly described as nearest definition wins. Use dependencyManagement or a BOM to control the version that ends up on the classpath.

A strong answer is:

Maven checks the local repo first, then remote repositories from the POM and settings mirrors, caching downloads under ~/.m2/repository. When versions conflict, nearest-wins mediation applies—I use dependency:tree and dependencyManagement or a BOM to verify the result.

If project A depends on B, and B depends on C, then C is a transitive dependency of A—you did not declare C, but Maven pulls it automatically.

Example:

your-app → spring-boot-starter-web → spring-web → spring-core

Inspect the graph:

mvn dependency:tree

Manage versions without repeating them in every module:

• Parent dependencyManagement
• BOM import scope
• maven-enforcer-plugin to ban divergent versions

A strong answer is:

Transitive dependencies are libraries your direct dependencies pull in automatically. I inspect them with mvn dependency:tree and align versions via BOM or dependencyManagement, using enforcer when teams need hard guarantees.

An excluded dependency is a transitive artifact you explicitly remove from the dependency graph using <exclusions>.

Scenario: Library B brings in outdated commons-logging, but you standardize on SLF4J. You depend on B but exclude commons-logging.

<dependency>
  <groupId>com.example</groupId>
  <artifactId>library-b</artifactId>
  <version>1.0</version>
  <exclusions>
    <exclusion>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>

After excluding, confirm nothing else reintroduces the JAR: mvn dependency:tree -Dincludes=commons-logging.

A strong answer is:

Excluded dependencies are transitive JARs I block with <exclusions> on a direct dependency. I always re-check dependency:tree because another path may still introduce the same artifact.

Mark a dependency <optional>true</optional> when your library can use it but consumers should not inherit it transitively.

Example: A logging adapter library depends on both SLF4J and Log4j2 bindings, but only one is needed per consumer.

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.23.1</version>
  <optional>true</optional>
</dependency>

Optional dependencies reduce classpath bloat for libraries with pluggable features.

A strong answer is:

Optional dependencies are not propagated transitively—the consumer must declare them explicitly. Library authors use <optional>true</optional> for pluggable features; consumers use exclusions to block unwanted transitives.

Maven provides flags for progressively more detail:

Examples:

mvn -e clean verify          # stack trace on failure
mvn -X clean verify            # full debug (large logs)
mvn -e -X clean verify         # both—use sparingly

Additional diagnostics:

mvn dependency:tree            # classpath / version conflicts
mvn help:effective-pom         # merged POM surprises
mvn -Dmaven.repo.local=/tmp/repo verify   # isolate corrupt local cache

Combine -e for the exception and dependency:tree when the failure is a missing class or version clash.

A strong answer is:

I start with mvn -e for stack traces on failure; escalate to mvn -X for plugin and resolution debugging. For dependency issues I pair that with mvn dependency:tree.

SNAPSHOT resolution: Maven may check remote snapshots daily (-U forces update: mvn -U clean install).

Release workflow: maven-release-plugin bumps versions, tags SCM, and deploys non-SNAPSHOT artifacts.

CI tip: pin release versions in production builds; use snapshots only for internal integration branches.

A strong answer is:

SNAPSHOT versions are mutable integration builds; release versions are immutable and reproducible. I never deploy snapshots to production, and I use mvn -U when I need the latest snapshot from the remote repo.

Unit tests run in the test phase via maven-surefire-plugin (default for JAR projects). Integration tests use maven-failsafe-plugin (integration-test / verify phases).

Run specific unit tests (Surefire):

mvn test -Dtest=OrderServiceTest
mvn test -Dtest=Order*Test
mvn test -Dtest=OrderServiceTest#shouldCreateOrder
mvn test -Dtest=OrderServiceTest,PaymentServiceTest

Integration tests (Failsafe):

mvn verify -Dit.test=OrderApiIT

Surefire and Failsafe use different property names (-Dtest vs -Dit.test) and naming conventions—keep integration tests on Failsafe during verify, not mixed into loose Surefire package patterns.

Surefire does not recompile tests if sources are unchanged—run mvn test-compile test after editing test sources.

A strong answer is:

Surefire runs unit tests in the test phase—I use mvn test -Dtest=ClassName or method-level filters. Failsafe handles integration tests with mvn verify -Dit.test=OrderApiIT.

test-compile succeeding but no tests executing usually points to Surefire configuration, not the compiler.

Diagnose:

mvn test -X 2>&1 | grep -i surefire
mvn surefire:test -Dtest=MyTest

Inspect effective config: mvn help:effective-pom | grep -A20 surefire

A strong answer is:

If tests compile but do not run, I check Surefire—-Dtest filters, skipTests, includes/excludes, and JUnit engine deps. mvn test -X shows which tests Surefire selected.

Two commonly confused properties—they are not equivalent:

Examples:

mvn package -DskipTests
mvn install -Dmaven.test.skip=true

POM-level (discouraged for production pipelines):

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <skipTests>true</skipTests>
  </configuration>
</plugin>

Failsafe (integration tests) is configured separately: use -DskipITs=true or <skipITs> in maven-failsafe-plugin. -DskipTests is commonly used for unit-test skipping and may also be honored by Failsafe depending on plugin version and configuration, but many teams prefer skipITs to control integration tests separately.

Prefer -DskipTests for unit tests when you still want compile-time validation of test code.

A strong answer is:

-DskipTests=true is the usual unit-test skip and still compiles tests; -Dmaven.test.skip=true skips both compile and run. For integration tests I use Failsafe's skipITs rather than assuming skipTests covers both plugins.

Yes, but Maven's defaults exist for a reason—override only for legacy code or generated sources.

Option 1 — Override standard directories in the POM:

<build>
  <sourceDirectory>src/java</sourceDirectory>
  <testSourceDirectory>src/test</testSourceDirectory>
  <directory>out</directory>
  <outputDirectory>out/classes</outputDirectory>
</build>

Option 2 — Add extra source roots with build-helper-maven-plugin (preferred for additional folders):

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>add-source</id>
      <phase>generate-sources</phase>
      <goals><goal>add-source</goal></goals>
      <configuration>
        <sources>
          <source>src/generated/java</source>
        </sources>
      </configuration>
    </execution>
  </executions>
</plugin>

A strong answer is:

Yes—set <sourceDirectory> / <testSourceDirectory> and <directory> in <build>, or add extra roots with build-helper-maven-plugin. For greenfield projects I stick to src/main/java and src/test/java.

Both orchestrate builds; they differ in model, flexibility, and ecosystem defaults.

Many organizations run both—Maven for legacy services, Gradle for Android or Kotlin microservices. Knowing Maven's lifecycle maps helps when reading Gradle's maven-publish output.

A strong answer is:

Maven is XML-driven with fixed lifecycle conventions; Gradle is a flexible task-graph DSL with stronger incremental builds. I pick Maven for standardized Java enterprise multi-module repos and Gradle when Android or heavy customization dominates.

Both use a parent POM, but they solve different problems.

They combine often: a root aggregator POM with <modules> also acts as <parent> for children.

root-pom (packaging=pom)
  ├── <modules> → api, service, web
  └── <dependencyManagement> → inherited by children via <parent>

Inheritance alone does not require modules to live in the same repo—parent can be published to Nexus. Multi-module requires the aggregator to list each module path.

A strong answer is:

Inheritance shares POM configuration via <parent>; multi-module aggregates subprojects in one reactor via <modules>. Real projects usually use a parent aggregator that both inherits config and lists modules.

Build portability is how easily a project builds on a fresh machine or CI agent without undocumented local tweaks.

Improve portability:

• Commit Maven Wrapper (mvnw)
• Document required JDK version in POM (maven-compiler-plugin) and CI
• Use .mvn/maven.config for shared flags
• Avoid system scope dependencies
• Store server credentials in CI secrets, not in committed settings.xml

A strong answer is:

A portable Maven build succeeds on any clean environment with only documented prerequisites—Wrapper, JDK version, and repo access. I avoid machine-specific paths, system-scope JARs, and undeclared settings.xml dependencies.

The Maven Wrapper (mvnw / mvnw.cmd + .mvn/wrapper/) downloads and runs a project-pinned Maven distribution so everyone and CI uses the same version.

Generate (once):

mvn wrapper:wrapper -Dmaven=<current-approved-maven-version>

Use the version approved by your team or CI image—not necessarily the newest release on publish day. Pin deliberately in .mvn/wrapper/maven-wrapper.properties so laptop and pipeline stay aligned.

Committed files:

Benefits:

• Eliminates "CI has Maven 3.6, laptop has 3.9" drift
• New developers run ./mvnw verify without installing Maven globally
• Reproducible builds pair well with locked pluginManagement versions

Trade-offs: Wrapper files under .mvn/wrapper/ are typically committed; exact layout depends on wrapper type. First run downloads Maven to ~/.m2/wrapper/dists/.

Usage:

./mvnw clean verify        # Linux/macOS
mvnw.cmd clean verify      # Windows

A strong answer is:

Maven Wrapper pins the Maven version per project—./mvnw downloads the right distribution so CI and developers stay aligned without a global Maven install.

A BOM is a POM with packaging=pom that lists dependencyManagement entries—version alignment without forcing every module to depend on every library.

Import a BOM:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>3.4.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Child module declares without version:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Custom BOM pattern: publish com.example:example-platform-bom:1.0.0 from a parent project; all microservices import it.

A strong answer is:

A BOM is an imported POM (type=pom, scope=import) that centralizes dependency versions in dependencyManagement. Modules declare artifacts without versions; I validate alignment with dependency:tree and enforcer rules.