Maven Profiles, settings.xml, Plugins & Quality Gates — Interview Questions

How to use this lesson

These questions separate "I've used Maven" from "I maintain the build". Watch the traps: environment-specific artifacts, FindBugs (long dead), and installing JARs by hand on laptops. The modern answers are build once, SpotBugs, and a repository manager.

Q1. How can Maven profiles be used to manage different environments?

Short answer: A profile changes the build: extra dependencies, plugin configuration, properties or modules. It's activated with -Pname, or automatically by JDK version, OS, a property or a missing file. Legitimate uses:

• optional build features (-Pnative, -Pintegration-tests, -Pcoverage);
• JDK- or OS-specific settings;
• release settings (signing, sources and Javadoc JARs).

Common trap: building different artifacts per environment (-Pprod baking the production database URL into the JAR). That breaks "build once, deploy everywhere", because what you tested isn't what you deploy. Keep the artifact environment-neutral, and inject environment configuration at runtime (Spring profiles, environment variables, a config server).

<profiles>
    <profile>
        <id>integration-tests</id>
        <build><plugins><plugin>
            <artifactId>maven-failsafe-plugin</artifactId>
            <executions><execution><goals><goal>integration-test</goal><goal>verify</goal></goals></execution></executions>
        </plugin></plugins></build>
    </profile>
</profiles>

Q2. Describe implementing a custom Maven plugin. What was the challenge?

Short answer (a model story): "We needed every service JAR to include a release-manifest.json with the git commit, dependency licences and API version, which no existing plugin produced in our format. I wrote a plugin: a Mojo class annotated with @Mojo(name = "manifest", defaultPhase = LifecyclePhase.PREPARE_PACKAGE), with @Parameter fields injected from the POM and the MavenProject for the dependency data. It's built with maven-plugin-plugin. The challenges were reproducibility (stable ordering, no timestamps, so builds stay byte-identical) and testing (the Maven plugin testing harness plus an integration test project). We published it to Nexus, and bound it in the parent POM."

Key points to cover:

• First check existing options: exec-maven-plugin, maven-antrun-plugin, build-helper, git-commit-id-maven-plugin. A custom plugin is justified when the logic is reused across many projects.

Q3. How can Maven generate project documentation automatically?

Short answer:

• The site lifecycle (mvn site, with maven-site-plugin) produces a website from reporting plugins: Javadoc, Surefire and Failsafe reports, JaCoCo coverage, dependency and licence reports, SpotBugs, Checkstyle.
• API docs: maven-javadoc-plugin (a -javadoc.jar for published libraries), OpenAPI specs from springdoc (springdoc-openapi-maven-plugin), or generated from the spec.
• Asciidoctor plus Spring REST Docs, for test-verified API documentation.

Key points to cover:

• Publish the documentation from CI (to GitHub Pages or an internal portal), so it never drifts from the code.

Q4. Scenario: the build fails because an external dependency is unavailable. What do you do?

Short answer:

1. Diagnose: is it the network, a proxy, credentials, a removed artifact, or an outage at the upstream repository? Run with -e/-X, check settings.xml mirrors, and check whether the version really exists.
2. Short term: use the company repository manager (Nexus or Artifactory) as a caching proxy. If the artifact was ever downloaded, it's still there. Or temporarily upload the exact artifact (verified by checksum) to the internal repository.
3. Long term: route all builds through the repository manager, pin versions (no floating LATEST/RELEASE), and avoid depending on obscure third-party repositories.

Common trap: mvn install:install-file on your laptop "fixes" your build, but not CI or your teammates' builds, and it hides the real problem. Use it only for a one-off local experiment.

Q5. How would you reduce the size of a Maven project and its artifacts?

Short answer:

• Remove unused dependencies: mvn dependency:analyze reports "declared but unused" and "used but undeclared".
• Exclude heavy transitive dependencies you don't need, such as an unused servlet container or duplicate logging bindings.
• Scope correctly: provided, test and runtime keep things out of the packaged artifact.
• Split a bloated module.
• For fat JARs, shrink the deployment rather than the JAR: use layered JARs and container layers, so dependencies are cached and each deploy ships only your code. maven-shade-plugin with minimizeJar only for libraries that must be self-contained.
• Keep generated and large binary files out of the repository.

Q6. What is settings.xml for?

Short answer: It configures Maven itself, on a given machine or user, rather than a project. User settings live in ~/.m2/settings.xml, and global ones in ${maven.home}/conf/settings.xml. It holds:

• repository credentials (<servers>, referenced by the ID of the repository or distribution entries);
• mirrors (route everything through the company Nexus);
• proxies;
• the local repository location;
• offline mode;
• profiles active by default (for example, adding internal repositories).

<settings>
  <mirrors>
    <mirror><id>company</id><mirrorOf>*</mirrorOf><url>https://nexus.acme.internal/repository/maven-all/</url></mirror>
  </mirrors>
  <servers>
    <server><id>company</id><username>${env.NEXUS_USER}</username><password>${env.NEXUS_TOKEN}</password></server>
  </servers>
</settings>

Key points to cover:

• Never put credentials in pom.xml. Keep them in settings.xml, encrypted with Maven's password encryption, or injected from environment variables or CI secrets.

Q7. Scenario: Maven build times keep increasing. How do you diagnose it?

Short answer:

1. Measure per module and per plugin. Maven 3.9 prints each module's time. -Dmaven.ext.class.path profilers or the Gradle Enterprise / Develocity build scans for Maven show where the time goes.
2. Check dependency resolution: repository timeouts, SNAPSHOT update checks (-nsu), misconfigured mirrors.
3. Check the tests: Surefire reports rank the slow tests. Look for Spring contexts being recreated, sleeps, and Testcontainers started per class.
4. Check the plugins: new code generators, reporting plugins bound to the default lifecycle, repeated work.
5. Compare with an older commit (git bisect on build time, if needed).

Then fix the biggest item, and track build time as a metric in CI.

Common trap: jumping straight to mvn -X. Debug logs are huge. Per-module and per-plugin timing tells you where to look first.

Q8. How do you enforce coding standards and static analysis in a Maven project?

Short answer: Bind quality plugins to the lifecycle, and fail the build on violations:

• Formatting: Spotless (auto-formats with spotless:apply, verifies with spotless:check).
• Style: Checkstyle.
• Bug patterns: SpotBugs (the maintained successor of the dead FindBugs), plus the FindSecBugs plugin for security, and PMD.
• Compile-time checks: Error Prone.
• Coverage gates: JaCoCo check.
• Dependency rules and vulnerability scanning: Enforcer; OWASP Dependency-Check or Snyk.
• Aggregated quality: a SonarQube quality gate in CI.

Key points to cover:

• Run the fast checks early (validate), and the slower analysis in verify. Keep the rule sets in a shared parent POM, so every service uses the same standards.

Q9. How do you use dependency:tree, and why is it useful?

Short answer: mvn dependency:tree prints the resolved dependency graph: every direct and transitive dependency, its version and scope. It's useful for:

• explaining where a library comes from (-Dincludes=groupId:artifactId);
• spotting conflicts (-Dverbose shows omitted duplicates, and why, for example "omitted for conflict with 2.17.0");
• auditing licences and vulnerabilities;
• finding bloat.

mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core
mvn dependency:tree -DoutputType=dot -DoutputFile=deps.dot     # visualise

Q10. Scenario: you need a specific version of a dependency that isn't compatible with the rest of your project. What do you do?

Short answer: First check whether you truly need it: a newer compatible release, a patch backport or an alternative library may exist. If you must have two incompatible versions:

• Shade and relocate the dependency in a small wrapper module, with maven-shade-plugin <relocations>. The copy then lives in a different package, and doesn't clash with the main version.
• Isolate it in a separate process or service.
• As a last resort, for plugins, use class-loader isolation.

When it's simply a version choice, pin the version with dependencyManagement, add the needed exclusions, and cover the risky integration with tests.

Key points to cover:

• Shading has costs: duplicated classes, bigger artifacts, and security patches in the shaded copy that you must track yourself. Treat it as a temporary measure, with an owner.

Follow-up questions this topic invites — and their answers

Q: What are Maven extensions, and when do you need them? A: Extensions (in .mvn/extensions.xml) hook into Maven's core. Examples are the build cache, custom wagons/transports, and Develocity build scans. They're for things plugins can't do.

Q: How do you make Maven builds reproducible? A: Set project.build.outputTimestamp, pin all plugin versions, avoid dynamic versions, and use the wrapper. Then verify by building twice, and comparing the checksums of the artifacts.

Q: What's the difference between mvn install and mvn deploy? A: install copies the artifact into your local repository (~/.m2). deploy uploads it to a remote repository, configured in distributionManagement, for others to use.

Q: What does the Maven Wrapper give you? A: A mvnw script plus .mvn/wrapper properties, which download and use the project's pinned Maven version. Every developer and CI job then uses the same Maven, with no installation needed.