Maven Builds, Multi-Module Projects & Dependency Resolution — Interview Questions

How to use this lesson

Level II Maven questions assume you've fought a real build: a dependency conflict, a slow CI pipeline, a multi-module refactor. Use precise mechanics (nearest wins, BOM import, reactor, -pl -am), and a short story wherever the question asks "describe a time".

Q1. Describe a complex Maven build you've configured. Which plugins and configuration mattered?

Short answer (a model build for a Spring Boot service):

• maven-compiler-plugin: release 21, -parameters, annotation processors (MapStruct, Lombok) in a defined order.
• maven-surefire-plugin runs the unit tests, and maven-failsafe-plugin runs *IT integration tests in integration-test/verify, using Testcontainers.
• jacoco-maven-plugin: coverage reports, plus a coverage gate in verify.
• maven-enforcer-plugin: requires the Maven and Java versions, and uses dependencyConvergence and banDuplicateClasses to catch conflicts early.
• Spotless or Checkstyle, and SpotBugs: code quality.
• spring-boot-maven-plugin: repackage into an executable JAR, build-info, and build-image for OCI images.
• openapi-generator-maven-plugin: generates API interfaces from the spec.
• flyway-maven-plugin, or migrations run at application startup.

Key points to cover:

• Bind plugins to the right phases, pin plugin versions (in pluginManagement), and keep CI and local builds identical with the Maven Wrapper.

Q2. How would you optimise a Maven build for a large multi-module project?

Short answer:

• Parallel reactor builds: -T 1C.
• Build only what changed: -pl changed-module -am (plus the modules it depends on), or -amd (plus the modules depending on it).
• The Maven Build Cache Extension, for incremental builds with local or remote caching.
• Keep modules cohesive, so the graph allows parallelism.
• Split slow integration tests into Failsafe and a separate CI stage.
• Use a nearby repository manager, and cache ~/.m2 in CI.
• Use mvnd (Maven Daemon) locally.
• Avoid expensive plugins in the default lifecycle (for example, run the site or reports only on demand).

Q3. How does Maven dependency resolution work? Describe a conflict you troubleshot.

Short answer: Maven builds the dependency graph (direct plus transitive dependencies), then mediates versions when the same artifact appears more than once:

• Nearest definition wins: the version closest to your POM in the tree.
• At equal depth, the first declaration wins.
• <dependencyManagement> (and imported BOMs) override both, pinning the versions for the whole build.

Scopes also affect what's visible where.

The story (model): "After adding an SDK, the app threw NoSuchMethodError in Jackson at startup. mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core showed the SDK pulling an older jackson-databind that was 'nearer' than Spring Boot's. I removed the override, let the Jackson BOM managed by Spring Boot pin the version, excluded the SDK's copy, and added an Enforcer dependencyConvergence rule so a drifting version would fail the build."

Q4. What is the purpose of pom.xml?

Short answer: It's the project's build model:

• coordinates (groupId:artifactId:version) and packaging;
• parent and modules;
• dependencies and dependencyManagement;
• build plugins and pluginManagement;
• properties, profiles, and repository or distribution settings.

Maven combines it with its parents (up to the super POM) into the effective POM, and executes it (mvn help:effective-pom shows the result).

Q5. Explain the Maven lifecycles and their phases.

Short answer: There are three lifecycles:

• clean: pre-clean, clean, post-clean.
• default: the build itself: validate, compile, test, package, integration-test, verify, install, deploy, and more.
• site: documentation.

Invoking a phase runs all the earlier phases of its lifecycle. Plugin goals bound to each phase (depending on the packaging, plus your own bindings) do the actual work.

Learn it in depth → Maven Interview Questions (fresher)

Q6. How do you manage a multi-module Maven project and its dependencies?

Short answer:

• A parent (aggregator) POM (<packaging>pom</packaging>) lists the <modules>, and centralises:
  • dependencyManagement: versions only, with no forced inclusion;
  • pluginManagement;
  • shared properties.
• Modules declare the dependencies they use, without versions.
• Inter-module dependencies use ${project.version}.
• Import BOMs (Spring Boot, Testcontainers) with <scope>import</scope>.

Key points to cover:

• Keep the module graph acyclic and layered (api → domain → persistence → app), so the reactor can build it in order and in parallel.
• Use the CI-friendly version property ${revision} with the flatten plugin, so a single version is set in one place.

Q7. How would you speed up Maven builds for large projects?

Short answer: Measure first (see "build time increasing", in the next lesson), then:

• -T 1C parallel builds.
• -o offline mode, when the cache is warm.
• The build cache extension.
• Selective builds (-pl/-am).
• Faster tests: parallel Surefire forks (forkCount), no Spring context in unit tests, reused Testcontainers.
• Skip non-essential plugins locally (-Dcheckstyle.skip), but never in CI.
• Cache dependencies in CI, near a repository manager.
• mvnd.

Q8. How do starters simplify Maven configuration?

Short answer: A Spring Boot starter is a single dependency that brings a curated, compatible set of libraries for one capability. For example, spring-boot-starter-data-jpa brings Hibernate, Spring Data JPA, HikariCP and the transaction support. Versions come from Boot's BOM, and the matching auto-configuration activates. You get fewer declarations, fewer version conflicts, and consistent setups across services.

Key points to cover:

• Companies build internal starters (acme-observability-starter) to standardise logging, tracing and security across teams.

Q9. Scenario: migrate a legacy project to Maven. How do you ensure a smooth transition?

Short answer:

1. Inventory the current build: Ant targets, lib/*.jar files, code generation, packaging, deployment steps.
2. Map the JARs to Maven coordinates. Identify each JAR by checksum and search Maven Central. Upload internal or unknown JARs to the company repository manager (not install:install-file on each laptop).
3. Adopt the standard layout (src/main/java, src/test/java, resources), or configure custom paths at first to reduce churn.
4. Recreate the build steps with plugins: code generation, WAR or JAR packaging, resources filtering.
5. Verify output equivalence. Compare the contents of the old and new artifacts, and run the tests and a smoke deployment.
6. Switch CI, run both builds in parallel for a while, then retire the old one.
7. Clean up afterwards: dependency convergence, a BOM, and removing unused JARs.

Q10. How do you handle version conflicts between dependencies in Maven?

Short answer:

1. Find them with mvn dependency:tree -Dverbose, and the Enforcer's dependencyConvergence rule.
2. Pin the version you want in <dependencyManagement>, preferably through the library's BOM (the Jackson, Netty or AWS SDK BOMs), so related modules stay aligned.
3. Exclude unwanted transitive copies with <exclusions>.
4. Test the chosen version against every consumer.

Common trap: believing the "newest version wins" automatically. Maven picks the nearest version, which may be the older one, and the result is NoSuchMethodError at runtime.

Follow-up questions this topic invites — and their answers

Q: dependencyManagement vs dependencies? A: dependencyManagement only declares versions and scopes. It doesn't add anything to the classpath. dependencies actually adds libraries. Child modules inherit the managed versions when they declare the dependency.

Q: What's the difference between Surefire and Failsafe? A: Surefire runs unit tests in the test phase, and fails the build immediately. Failsafe runs integration tests in integration-test, and fails in verify, so post-integration-test teardown (such as stopping containers) still runs.

Q: What's a BOM? A: A "bill of materials": a POM that exists only to manage versions for a family of artifacts. You import it into <dependencyManagement> with type pom and scope import.

Q: What does mvn verify do that mvn package doesn't? A: It also runs the integration tests and verification checks (coverage gates, Enforcer rules bound to verify). It's the right default command for CI.