Maven & Gradle at Scale — Interview Questions

How to use this lesson

Build questions at this level are about reproducibility, speed and governance across many modules and teams:

• centralised versions (BOMs, version catalogues);
• shared conventions (parent POMs, convention plugins);
• caching and parallelism;
• clean artifact publishing.

Q1. How do you override a dependency version in a multi-module project?

Short answer:

• Maven:

  • declare the desired version in the root or parent POM's <dependencyManagement>, which controls the version for every module, including transitive occurrences;
  • when using Spring Boot's parent, override the version property (<jackson-bom.version>2.18.2</jackson-bom.version>), which is the cleanest way to bump a Boot-managed library;
  • with Boot imported as a BOM (scope import), declare your override before the Boot BOM in dependencyManagement (the first declaration wins).

  Verify with mvn dependency:tree -Dincludes=groupId:artifactId.

• Gradle:

  • set the version in the version catalogue (libs.versions.toml), or a platform;
  • use constraints { implementation("…:2.18.2") }, or strictly versions, for enforcement;
  • use a resolutionStrategy.force only as a last resort.

  Inspect with ./gradlew dependencyInsight --dependency jackson-databind.

Q2. What's the difference between dependencyManagement and dependencies in Maven?

Short answer:

• <dependencies> actually adds the dependencies to the module's classpath (and they're inherited by child modules, if declared in a parent).
• <dependencyManagement> only declares versions, scopes and exclusions for dependencies if and when a module uses them. It doesn't add them. Child modules then declare the dependency without a version. That's how you get consistent versions across modules, without forcing every module to include every library. Importing a BOM (<type>pom</type><scope>import</scope>) inside dependencyManagement pulls in a whole curated version set.

Q3. What's the benefit of a Maven BOM (Bill of Materials)?

Short answer: A BOM is a POM that contains only dependencyManagement, for a coherent set of artifacts: spring-boot-dependencies, jackson-bom, testcontainers-bom, aws-sdk-bom, or your organisation's platform BOM. Importing it gives:

• aligned, tested versions across related libraries (no mismatched Jackson modules);
• no version numbers scattered in modules;
• central upgrades: bump one BOM version;
• the ability to use several BOMs (unlike the single <parent>).

Gradle's equivalent is implementation(platform("…:bom:x")) (or enforcedPlatform).

Q4. How do Maven parent and child POMs work?

Short answer:

• Inheritance (<parent>): a child inherits the parent's groupId/version, properties, dependencyManagement, pluginManagement, dependencies, plugin configuration, repositories and profiles. It can override them. It's used for shared build conventions (the compiler release, plugin versions, Surefire configuration, quality plugins). The Spring Boot starter parent is an example.
• Aggregation (<modules>): a POM with packaging pom lists modules, so one build runs them all, in reactor order (computed from their inter-dependencies).
• They're often the same root POM, but they're different concepts: you can aggregate without inheriting, and vice versa. Resolve relativePath carefully when the parent isn't in the directory above.
• Limitation: a single parent, so use BOM imports for extra version sets.

Q5. How can you profile, or speed up, your build in Maven?

Short answer:

• Measure:

  • Maven's -Dprofile isn't built in, so use the Maven Build Time Profiler extension or buildtime-maven-extension;
  • timestamps with -X/-B and -Dorg.slf4j.simpleLogger.showDateTime=true;
  • Gradle Enterprise/Develocity build scans, which work for Maven too.

  Find the slow plugins and modules (tests, annotation processing, shading).

• Speed it up:

  • parallel builds (-T 1C);
  • skip unchanged work (build only the changed modules: -pl moduleA -am);
  • the Maven build cache extension;
  • faster tests (split unit and integration tests, and parallelise Surefire);
  • offline mode with a warm local repository, or a CI cache of ~/.m2;
  • avoid unnecessary plugins in the default lifecycle (run Javadoc and site generation only on release);
  • the Maven Daemon (mvnd) for local builds;
  • dependency hygiene (dependency:analyze).

• Maven profiles (<profiles>) are a different concept: environment- or condition-specific build configuration (see Q13).

Q6. What are maven-compiler-plugin and maven-surefire-plugin for?

Short answer:

• maven-compiler-plugin: compiles src/main/java and src/test/java. Configure it with <release>21</release> (preferred over source and target, because it also checks the API usage against that JDK), with annotation processors (annotationProcessorPaths for Lombok, MapStruct, the Spring configuration processor, Hibernate JPA metamodel), -parameters (needed for Spring parameter-name binding), and compiler warnings (-Xlint).
• maven-surefire-plugin: runs unit tests in the test phase (JUnit 5 through the JUnit Platform), with includes and excludes, forking and parallelism, system properties, and reports. Failsafe runs integration tests (*IT) in the integration-test and verify phases, so post-integration cleanup (stopping containers) still happens before the build fails.

Q7. How do you create a shaded, or fat, JAR in Maven?

Short answer:

• For Spring Boot applications: use the spring-boot-maven-plugin (repackage). It creates an executable JAR with nested JARs (BOOT-INF/lib) and a custom launcher. It isn't shading: no class relocation is needed.
• For plain applications or libraries: use the maven-shade-plugin, which merges all dependency classes into one JAR. It can relocate packages (com.google.common → myapp.shaded.guava), to avoid conflicts with the host application's versions (important for libraries and Hadoop/Spark jobs). Transformers merge META-INF/services files and set the Main-Class. maven-assembly-plugin (jar-with-dependencies) is the older, simpler alternative, without relocation.
• Caveats: licence and notice files, signed JAR signatures (strip them), duplicate resources, and a large artifact size.

Q8. What's the difference between the package, install and deploy goals in Maven?

Short answer: They're lifecycle phases (each runs all the earlier phases):

• package: compile, test, and build the artifact (JAR or WAR) in target/.
• install: package, plus verify, then copy the artifact into the local repository (~/.m2/repository), so other local projects can depend on it.
• deploy: install, then upload the artifact to a remote repository (Nexus, Artifactory, GitHub Packages), as configured in distributionManagement. It's used in CI for releases and snapshots.

mvn clean install in CI is often unnecessary. mvn verify is enough, unless downstream local modules need the artifacts.

Q9. What's the difference between implementation and api in Gradle?

Short answer: Both come from the java-library plugin:

• api: the dependency is part of this module's public API (its types appear in public method signatures). It leaks to consumers' compile classpaths.
• implementation: an internal dependency. It's on this module's compile classpath, and the consumers' runtime classpath, but not on their compile classpath.

The benefits of implementation:

• faster builds (changing an implementation dependency doesn't recompile the consumers);
• better encapsulation (consumers can't accidentally use transitive internals).

Use api only when necessary. Other configurations: compileOnly (like Maven's provided: Lombok, annotations), runtimeOnly (JDBC drivers), testImplementation, and annotationProcessor.

Q10. How do you apply plugins or dependencies conditionally in Gradle?

Short answer:

• In the build script (it's code):

if (providers.gradleProperty("withNative").isPresent) {
    apply(plugin = "org.graalvm.buildtools.native")
}
dependencies {
    if (project.hasProperty("postgres")) runtimeOnly("org.postgresql:postgresql")
    else runtimeOnly("com.h2database:h2")
}

• pluginManager.withPlugin("java") { … }: react when another plugin is applied (common in convention plugins).
• Feature variants or capabilities, for optional features of a library.
• Keep conditions deterministic and cache-friendly: use providers (providers.gradleProperty, providers.environmentVariable), so the configuration cache works. Avoid System.getenv reads at configuration time.

Q11. How do you trigger tasks in a specific order across multiple modules?

Short answer:

• Model real dependencies: dependsOn (task A needs B's output), or better, wire the task inputs to the outputs of the other tasks (from(project(":api").tasks.named("openApiGenerate"))), so Gradle infers the ordering and caching correctly.
• Ordering without dependency: mustRunAfter/shouldRunAfter (for example, integration tests after unit tests if both run).
• finalizedBy, for cleanup tasks.
• Cross-project tasks: dependsOn(":module:task"), or aggregation tasks in the root. Avoid cross-project configuration (allprojects {} mutating others); prefer convention plugins.
• In Maven, the ordering comes from module dependencies (the reactor order) plus phase bindings; plugins bound to the same phase run in declaration order.

Q12. How do you run specific tests or tasks from the Gradle command line?

Short answer:

./gradlew :orders:test --tests "com.shop.orders.CheckoutServiceTest"            # one class
./gradlew test --tests "*CheckoutServiceTest.rejectsEmptyCart"                   # one method
./gradlew :orders:integrationTest -PincludeTags=slow                             # a custom property
./gradlew build -x test                                                          # exclude a task
./gradlew :orders:bootRun --args='--spring.profiles.active=local'
./gradlew tasks --all                                                            # list tasks
./gradlew test --rerun                                                           # force a rerun (ignore up-to-date)
./gradlew build --scan                                                           # a build scan for diagnostics

In Maven: mvn -pl orders -Dtest=CheckoutServiceTest#rejectsEmptyCart test, and -Dit.test=... for Failsafe.

Q13. What are project properties, and how do you use them? How do you set up and activate build profiles (dev, test, prod)?

Short answer:

• Gradle project properties: from gradle.properties (project, or user home ~/.gradle), -Pname=value on the command line, or ORG_GRADLE_PROJECT_name environment variables. Read them with providers.gradleProperty("name"). They're used for versions, feature switches, credentials (from the user-home properties, never committed), and environment selection.
• Maven properties: <properties> in the POM, -Dname=value, and settings.xml.
• "Profiles":
  • Maven <profiles>, activated with -Pprod, or automatically by JDK, OS, property or file presence;
  • Gradle has no built-in profiles: use properties (-Penv=prod) and conditional logic, or separate tasks.
• Best practice: don't build different artifacts per environment. Build one artifact, and select the environment at runtime (Spring profiles, environment variables). Keep build profiles for build variations: skipping slow checks, native builds, release signing.

Q14. What are the best practices for multi-module builds? How do you share dependencies and plugins across modules?

Short answer:

• Structure:
  • modules along architectural boundaries (API, domain, adapters, application), with acyclic dependencies;
  • keep the module count reasonable;
  • use api vs implementation (Gradle) to limit leakage.
• Centralise the versions:
  • Maven: a parent POM plus dependencyManagement and BOMs;
  • Gradle: a version catalogue (gradle/libs.versions.toml) and platforms.
• Share the conventions:
  • Maven: a parent POM with pluginManagement and shared plugin configuration;
  • Gradle: convention plugins in build-logic (an included build, id("shop.java-conventions")), not allprojects/subprojects blocks, which couple the projects and break configuration caching.
• Performance: parallel builds, build caching (local and remote), the configuration cache, incremental compilation, and avoiding configuration-time work.
• Quality: apply static analysis, test and coverage conventions through the shared plugins, and enforce dependency rules (ArchUnit, and the dependency-analysis plugin).
• Reproducibility: the wrapper (mvnw/gradlew) committed to the repository, pinned plugin versions, and dependency locking or verification (gradle/verification-metadata.xml).

Q15. How do you produce separate build artifacts for test classes and main classes?

Short answer:

• Maven: the maven-jar-plugin's test-jar goal produces *-tests.jar. Consumers depend on it with <type>test-jar</type> (or <classifier>tests</classifier>) and <scope>test</scope>. It's used to share test utilities or fixtures. The cleaner alternative is a dedicated *-test-support module.
• Gradle: the java-test-fixtures plugin: src/testFixtures/java, with consumers using testImplementation(testFixtures(project(":orders"))). Or publish an extra artifact with a classifier.

Prefer test-support modules or test fixtures over exporting whole test source sets, which drags in the test dependencies and the tests themselves.

Q16. How do you run parallel builds in Maven or Gradle?

Short answer:

• Maven:
  • mvn -T 1C verify (one thread per core; or -T 4) builds independent modules in parallel (following the reactor graph);
  • plugins must be thread-safe (most modern ones are);
  • combine it with parallel tests (Surefire parallel/forkCount), and mvnd.
• Gradle:
  • org.gradle.parallel=true (in gradle.properties) runs tasks of decoupled projects in parallel;
  • maxParallelForks for test JVMs;
  • org.gradle.workers.max;
  • plus the configuration cache (org.gradle.configuration-cache=true) and build cache (org.gradle.caching=true), for bigger wins.
• Watch out for: shared resources (ports, databases) in tests running in parallel, and memory limits on CI agents.

Q17. What's the difference between build.gradle.kts and build.gradle?

Short answer:

• build.gradle uses the Groovy DSL: dynamic and concise, with weaker IDE support and fewer compile-time errors.
• build.gradle.kts uses the Kotlin DSL: statically typed, with excellent IDE auto-completion, navigation and refactoring, and compile-time errors. The first configuration can be slightly slower (script compilation, which is cached). It's the default for new Gradle projects (and Spring Initializr offers it).

Both configure the same Gradle API. Kotlin is recommended for maintainability, especially with convention plugins in build-logic.

Follow-up questions this topic invites — and their answers

Q: What is the Gradle configuration cache? A: It caches the result of the configuration phase (the task graph), so later builds skip configuration entirely. That's a big speed-up for large builds. It requires build logic to avoid configuration-time side effects, and to use lazy providers.

Q: How do you prevent dependency-confusion attacks? A: Resolve internal group IDs only from the internal repository (Gradle exclusiveContent/repository content filtering, and Maven mirror settings routing everything through Nexus or Artifactory), and use dependency verification (checksums or signatures).

Q: What does mvn dependency:analyze report? A: "Used undeclared" dependencies (you rely on transitive ones, so declare them explicitly) and "unused declared" dependencies (candidates for removal). It keeps the dependency graph honest.

Q: Maven or Gradle for a new Spring Boot project? A: Both are fully supported. Maven means convention and simplicity, and it's ubiquitous. Gradle means faster incremental builds, caching and flexible logic, at the cost of more complexity. Choose based on the team's familiarity and the build's complexity.