Maven Interview Questions and Answers

What interviewers are testing: Whether you understand Maven as a declarative project/build model driven by lifecycle phases and plugins, not just a dependency downloader.

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.

What interviewers are testing: Whether you can connect Maven's conventions, lifecycle, repositories, plugins, and dependency graph into one build model.

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.

What interviewers are testing: Whether you distinguish core Maven lifecycle behavior from capabilities supplied by plugins.

Maven provides the lifecycle and plugin execution model; plugins add capabilities such as release automation, SCM operations, documentation, quality checks, and publishing.

In practice, CI pipelines call Maven for the repeatable core—mvn verify or mvn deploy—while plugins supply the concrete work bound to lifecycle phases.

A strong answer is:

Maven provides lifecycle phases and plugin execution; plugins handle compile, test, release, reporting, documentation, and publishing work through goals bound to that lifecycle.

What interviewers are testing: Whether you understand where Maven's standardization helps teams and where convention becomes restrictive.

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.

What interviewers are testing: Whether you can explain convention over configuration with concrete layout and lifecycle defaults—not as a slogan.

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.

What interviewers are testing: Whether you understand how a build tool maps compile, test, package, and deploy work to repeatable automation.

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.

What interviewers are testing: Whether you can contrast procedural Ant scripts with Maven's declarative lifecycle and dependency model.

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 remains extremely common in enterprise Java; Gradle is another major modern build system.

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.

What interviewers are testing: Whether you distinguish a plugin, goal, MOJO, and lifecycle phase.

A Mojo is the implementation class for a Maven plugin goal. Historically Maven documentation expanded MOJO as Maven plain Old Java Object, but the useful distinction is plugin → goal/Mojo → lifecycle phase binding.

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 the Java class that implements a plugin goal—Maven executes it when a lifecycle phase triggers a bound plugin or when you invoke the goal directly.

What interviewers are testing: Whether you understand the relationship between artifact coordinates, metadata, local caching, and remote resolution.

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.

What interviewers are testing: Whether you distinguish local repository from remote repositories and mirrors, rather than treating Central as another repository type.

Maven distinguishes local vs remote repositories in the resolution chain:

Maven Central is the default public remote repository—not a separate repository type, but the default public remote most projects use.

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 and remote repositories such as Maven Central or corporate proxies—I don't confuse Central with a different repository type; it's the default public remote.

What interviewers are testing: Whether you understand the local repository as Maven's per-machine cache and install target.

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.

What interviewers are testing: Whether you know Maven Central's role as the default public remote—not a separate repository type.

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.

What interviewers are testing: Whether you can describe how remote repositories, mirrors, and credentials fit into resolution.

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.

What interviewers are testing: Whether you understand why artifact repositories beat checking binaries into version control.

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.

What interviewers are testing: Whether you know Central publishing is gated, signed, and separate from internal repository managers.

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.

What interviewers are testing: Whether you understand the effective model produced from project, parent, profiles, and Super POM defaults.

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 builds use an aggregator POM with <modules> listing projects built together. That aggregator often also acts as the parent, but inheritance is separate: a module inherits shared dependency/plugin management only when its POM declares that parent.

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.

What interviewers are testing: Whether you know which defaults come from inheritance versus lifecycle/packaging conventions.

The Super POM provides inherited baseline configuration. Maven's lifecycle and packaging mappings supply default plugin-goal bindings. Parent POMs and project POMs further override or extend these values. help:effective-pom shows the merged result.

View effective defaults with:

mvn help:effective-pom

The Super POM contributes inherited default configuration such as repositories and plugin-related defaults. Maven's project conventions and lifecycle/packaging mappings provide other defaults such as the standard source layout (src/main/java, src/test/java), output location (target/), 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 contributes inherited default configuration such as repositories and plugin-related defaults; Maven's project conventions and lifecycle/packaging mappings provide other defaults such as the standard source layout and lifecycle bindings—I use help:effective-pom to see the merged result and pin plugin versions in pluginManagement.

What interviewers are testing: Whether you distinguish elements physically present in a child POM from coordinates inherited into its effective model.

Every Maven POM needs a modelVersion and artifactId. A project's effective coordinates also require groupId and version, but child projects can inherit groupId and/or version from their parent POM.

<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 and artifactId; groupId and version are required for effective coordinates but may be inherited from a parent POM.

What interviewers are testing: Whether you understand phase ordering and plugin-goal bindings, not merely memorize phase names.

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:

Plugin goals are bound to lifecycle phases. You normally invoke the phase you want—such as mvn verify—and Maven runs that phase plus all preceding phases in the same lifecycle.

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.

What interviewers are testing: Whether you know which lifecycle phase produces artifacts versus install or deploy.

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.

What interviewers are testing: Whether you distinguish artifact identity from command-specific colon syntax.

The core identity is commonly described as GAV: groupId, artifactId, and version. Type/extension and classifier further distinguish variants.

Some Maven plugin CLI parameters serialize these fields in plugin-specific colon formats—for example, dependency:get accepts groupId:artifactId:version[:packaging][:classifier]. Check the command's documented order rather than assuming one universal colon string is the artifact model itself.

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

A strong answer is:

Maven artifacts are identified by GAV plus optional type and classifier—I use plugin-documented colon syntax only when a specific CLI command requires it.

What interviewers are testing: Whether you know clean, default, and site are independent lifecycles with separate phase sequences.

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.

What interviewers are testing: Whether you understand archetypes as reusable templates that encode team project standards.

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.

What interviewers are testing: Whether you can scaffold projects with archetype:generate interactively or via properties.

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.

What interviewers are testing: Whether you understand that Maven core work is plugin goals bound to lifecycle phases.

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.

What interviewers are testing: Whether you can trace effective plugin versions with help:describe and effective-pom.

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.

What interviewers are testing: Whether you understand where profiles live, what each kind may change, and why overusing environment profiles hurts reproducibility.

POM profiles can vary project build configuration such as dependencies, plugins, properties, and repositories. Profiles in settings.xml are intentionally narrower and are limited mainly to properties, repositories, plugin repositories, and activation settings.

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.

What interviewers are testing: Whether you distinguish machine/user Maven configuration from project build configuration.

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.

What interviewers are testing: Whether you distinguish machine/user Maven configuration from project build configuration.

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.

What interviewers are testing: Whether you confirm which Maven and JDK versions are active before blaming plugin or compiler errors.

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.

List every PATH match with which -a; the which command compares which to type -a and command -v.

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.

What interviewers are testing: Whether you can verify Maven on Windows via PATH, JDK, and Wrapper without legacy M2_HOME assumptions.

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 and where.exe mvn; if it fails I confirm Maven bin is on PATH and the reported JDK is correct. On Wrapper projects I use mvnw.cmd instead.

What interviewers are testing: Whether you distinguish artifact identity from command-specific colon syntax.

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 (see zip).

Coordinates identify an artifact by groupId, artifactId, version, plus optional extension/type and classifier. Plugin CLIs may serialize these as colon-separated strings in plugin-specific formats.

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

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.

What interviewers are testing: Whether you know default output directories for main and test compilation.

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.

What interviewers are testing: Whether you know Maven's standard project layout and when overrides are justified.

Maven's convention over configuration defaults:

Other conventional roots:

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

These paths are Maven's standard project/build-model conventions and defaults. They should not all be attributed solely to the Super POM—use help:effective-pom for inherited/configured values. 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.

What interviewers are testing: Whether you understand jar:jar packages compiled classes during package without recompiling.

For a project with packaging=jar, the Maven JAR Plugin's jar:jar goal is bound to the package phase by default and 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.

What interviewers are testing: Whether you can predict classpath and transitivity behavior, not just name six scopes.

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.

What interviewers are testing: Whether you can identify the specific dependency path introducing an unwanted transitive before excluding it.

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.

What interviewers are testing: Whether you understand transitive graph construction, mediation, repositories, mirrors, and local caching.

Maven consults the local repository/cache and repository metadata/update policies, then resolves missing or refreshable artifacts from configured remote repositories/mirrors. Release artifacts normally reuse the cached copy; snapshots may be checked for updates according to repository policy or -U.

Resolution flow (simplified):

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 consults local cache and update policies, then fetches missing or refreshable artifacts from remotes/mirrors. When versions conflict, nearest-wins mediation applies—I use dependency:tree and dependencyManagement or a BOM to verify the result.

What interviewers are testing: Whether you understand transitive graph construction, mediation, repositories, mirrors, and local caching.

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.

What interviewers are testing: Whether you can identify the specific dependency path introducing an unwanted transitive before excluding it.

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.

What interviewers are testing: Whether you distinguish a provider declaring a feature optional from a consumer excluding a transitive dependency.

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 are not propagated transitively—consumers needing that feature must declare it explicitly. Library authors use <optional>true</optional> for pluggable features; consumers use exclusions to block unwanted transitives.

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.

What interviewers are testing: Whether you escalate from normal failure output to stack traces, effective model, dependency graph, and full debug logging appropriately.

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.

What interviewers are testing: Whether you understand mutable development coordinates versus stable release coordinates and repository update policies.

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

Traditional option: maven-release-plugin can manage version changes, SCM tagging, and release preparation. Modern CI pipelines may perform those steps independently and simply run Maven to build/sign/deploy the release.

Treat release coordinates as immutable even if an internal repository technically permits redeployment.

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.

What interviewers are testing: Whether you understand which lifecycle owns unit versus integration-test execution.

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.

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.

What interviewers are testing: Whether you understand which lifecycle owns unit versus integration-test execution.

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

Diagnose:

mvn test -Dtest=MyTest          # preferred for normal diagnosis
mvn test -X 2>&1 | grep -i surefire

Directly invoking mvn surefire:test runs the goal against already-prepared outputs and can bypass preceding lifecycle phases—use it only when classes are already compiled.

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.

What interviewers are testing: Whether you distinguish Surefire skip flags from Failsafe's skipITs and maven.test.skip.

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: -DskipTests can also affect Failsafe, but Failsafe's skipTests parameter is deprecated. Use -DskipITs when you specifically want to skip integration tests while preserving unit-test behavior.

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.

What interviewers are testing: Whether you know when to override standard directories versus add extra roots with build-helper.

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.

What interviewers are testing: Whether you can compare build models and trade-offs without overstating universal winners.

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 uses a lifecycle-and-plugin model with XML configuration; Gradle uses a programmable task graph. I compare trade-offs—convention versus customization, ecosystem fit, and team standards—rather than claiming one tool always wins.

What interviewers are testing: Whether you know configuration inheritance and reactor aggregation are independent relationships.

Inheritance and aggregation are independent Maven relationships. A POM can be a parent, an aggregator, both, or neither.

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.

What interviewers are testing: Whether a clean agent can reproduce the build without hidden local state.

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.

What interviewers are testing: Whether you know exactly what the Wrapper pins—and what it does not pin.

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
• Pin/verify Wrapper downloads with distributionSha256Sum (and wrapperSha256Sum where applicable) when supply-chain controls require it
• New developers run ./mvnw verify without installing Maven globally
• Maven Wrapper removes Maven-version drift between developer and CI environments; full reproducibility also requires pinning the rest of the build inputs (JDK, plugin versions, dependencies, repository contents, timestamps/build metadata, and OS/tooling where relevant)

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; full reproducibility still depends on pinning JDK, plugins, dependencies, and other build inputs.

What interviewers are testing: Whether you understand that BOM import manages versions without adding all managed dependencies.

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>${spring-boot.version}</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.

What interviewers are testing: Whether you can separate Maven 4-only build-model features from features compatible with existing Maven 3 POMs.

Interviews may increasingly ask about Maven 4 features while most existing builds still run on Maven 3.

A strong answer is:

Maven 3.9.16 is the current recommended Maven 3 release and Maven 3 remains widely used in existing builds; Maven 4 is the RC evolution that requires Java 17, uses model 4.1.0, adds dedicated BOM packaging, and changes defaults such as installAtEnd/deployAtEnd—I know which features require upgrading versus staying on Maven 3.