Gradle Fundamentals, Migration & Dependencies — Interview Questions

How to use this lesson

Modern Gradle answers use the Kotlin DSL, version catalogs, convention plugins and configuration avoidance. Answers built around Groovy subprojects {} blocks, JCenter and compile configurations date from around 2018. Show the current idioms.

Q1. What's the difference between Maven and Gradle?

Short answer:

Key points to cover:

• Both use Maven repositories and coordinates, and Spring Boot supports both equally. Choose based on build size and complexity, and on your team's skills.

Q2. What challenges come with migrating from Maven to Gradle, and how do you handle them?

Short answer:

1. Bootstrap with gradle init, which converts a POM into a starting build (review the result, don't trust it blindly).
2. Recreate the dependency management: the BOMs become platform(...), versions go into a version catalog (gradle/libs.versions.toml), and the scopes map to configurations (compile → implementation/api, provided → compileOnly, runtime → runtimeOnly, test → testImplementation).
3. Replace Maven plugins with Gradle equivalents, or custom tasks. Check that code generation, packaging, publishing and integration tests all behave the same way.
4. Handle the conflict-resolution difference. Gradle picks the highest version, so the resolved versions can change. Compare the dependency reports from both builds.
5. Verify output equivalence: artifact contents, test counts, published POM metadata.
6. Migrate CI. Run both builds side by side for a while, then switch.
7. Train the team on Gradle idioms, so the build doesn't become unmaintainable.

Q3. How do you manage library dependencies in a Gradle project?

Short answer: Declare them in dependencies {} with the right configuration, keep their versions in a version catalog, and use platforms (BOMs) to align families of libraries.

// build.gradle.kts
dependencies {
    implementation(platform(libs.spring.boot.bom))       // BOM → aligned versions
    implementation(libs.spring.boot.starter.web)
    api(libs.money.api)                                   // exposed to consumers of this module
    compileOnly(libs.lombok)
    annotationProcessor(libs.lombok)
    runtimeOnly(libs.postgresql)
    testImplementation(libs.junit.jupiter)
}
repositories { mavenCentral() }

Key points to cover:

• implementation vs api: implementation hides the dependency from consumers' compile classpaths, which gives faster recompilation and less leakage. Use api only when the types appear in your public API (this needs the java-library plugin).
• JCenter is shut down. Use mavenCentral() and your company repository.

Q4. Scenario: you need a multi-project Gradle build. What do you take into account?

Short answer:

• settings.gradle.kts declares the modules (include("api", "domain", "persistence", "app")), and dependency resolution management (repositories, version catalogs).
• Put shared build logic in convention plugins (build-logic/ as an included build, or buildSrc), such as java-conventions and spring-service-conventions, and apply them per module. Avoid the older allprojects {} / subprojects {} cross-configuration: it breaks isolation and the configuration cache.
• Keep the module graph acyclic and layered, and use project(":domain") dependencies.
• Use one version catalog for all modules.
• Enable parallel execution, the build cache and the configuration cache.

Q5. How does Gradle's incremental build work, and what are its advantages?

Short answer: Every task declares its inputs (source files, properties, classpath) and outputs (directories, files). Gradle fingerprints them. If nothing changed since the last run, and the outputs still exist, the task is UP-TO-DATE and is skipped. Java compilation is also incremental within a task, recompiling only the affected classes. The build cache extends this across branches, machines and CI (the task is loaded FROM-CACHE).

Advantages: much faster edit-build-test cycles, and faster CI, especially in large multi-module builds.

Key points to cover:

• Custom tasks must declare their inputs and outputs correctly (@InputFiles, @OutputDirectory). Otherwise they always run, or, worse, are wrongly skipped.

Q6. Describe troubleshooting a complex Gradle build script.

Short answer (a model story): "After an upgrade, the build failed with a NoSuchMethodError from a Jackson class, but only in CI. ./gradlew dependencyInsight --dependency jackson-databind --configuration runtimeClasspath showed that a plugin's transitive dependency upgraded Jackson beyond what our framework supported. The build scan (--scan) confirmed that CI resolved differently because of a stale lock file. I aligned Jackson through the BOM platform, added dependency locking, and a failOnVersionConflict() check for critical groups. Other tools I rely on: --stacktrace/--info, ./gradlew help --task <name>, and ./gradlew :app:dependencies."

Q7. How do you write a custom Gradle task, and what are some use cases?

Short answer: Register a task lazily with tasks.register. For anything non-trivial, write a task class with typed, annotated inputs and outputs, so it's cacheable and incremental.

abstract class GenerateBuildInfo : DefaultTask() {
    @get:Input abstract val version: Property<String>
    @get:OutputFile abstract val output: RegularFileProperty
    @TaskAction fun write() {
        output.get().asFile.writeText("""{"version":"${version.get()}"}""")
    }
}

tasks.register<GenerateBuildInfo>("buildInfo") {
    version = project.version.toString()
    output = layout.buildDirectory.file("generated/build-info.json")
}
tasks.named("processResources") { dependsOn("buildInfo") }

Use cases: generating code or metadata, running a database migration check, packaging extra artifacts, verifying licences, starting and stopping test infrastructure, and custom release steps.

Q8. Scenario: a Gradle build fails because of a version conflict. How do you resolve it?

Short answer:

1. Find it: ./gradlew dependencyInsight --dependency <lib> --configuration runtimeClasspath explains which version was chosen and why.
2. Fix it, preferring the least forceful option:
   • Align the family with a platform/BOM (implementation(platform(...))).
   • Add a dependency constraint (constraints { implementation("lib:1.2.3") }), with a reason.
   • Exclude a transitive dependency.
   • Only as a last resort, resolutionStrategy.force(...), which hides future conflicts.
3. Prevent recurrence: dependency locking, failOnVersionConflict() for critical groups, and Renovate or Dependabot for controlled upgrades.

Q9. How do you manage environment-specific configuration in a Gradle project?

Short answer: Keep the artifact environment-neutral, and supply environment configuration at runtime: Spring profiles, environment variables, a config server. The build shouldn't care whether it's heading for dev or prod. Gradle properties (-Pfoo, gradle.properties) are for build options (enabling integration tests, signing, a native build), not for application settings such as database URLs.

Common trap: separate dev.gradle/prod.gradle files that bake in different URLs. That produces different binaries per environment, which is the same anti-pattern as Maven profiles used for environments.

Q10. What's the significance of build.gradle(.kts), and how is it structured?

Short answer: It's the build script for a project. It configures that project's plugins, dependencies and tasks. A typical structure:

plugins {                                  // 1. plugins (convention plugins preferred)
    id("acme.spring-service-conventions")
    alias(libs.plugins.spring.boot)
}
group = "com.acme.orders"                  // 2. coordinates
version = "1.4.0"
java { toolchain { languageVersion = JavaLanguageVersion.of(21) } }   // 3. extensions config
dependencies { … }                         // 4. dependencies
tasks.test { useJUnitPlatform() }          // 5. task configuration

Key points to cover:

• settings.gradle.kts defines the build (its modules, plugin management, repositories and catalogs). gradle.properties holds build flags (org.gradle.caching=true, org.gradle.configuration-cache=true).
• Java toolchains make the JDK used for compiling independent of the JDK that runs Gradle.

Follow-up questions this topic invites — and their answers

Q: What is a version catalog? A: A TOML file (gradle/libs.versions.toml) that centralises library and plugin coordinates and versions, and generates type-safe accessors (libs.spring.boot.starter.web) shared by all modules.

Q: Groovy DSL or Kotlin DSL? A: Kotlin DSL (.gradle.kts) gives type safety, IDE completion and refactoring support, and has been the default for new builds since Gradle 8.2. Groovy still works, and appears in many older builds.

Q: What is the configuration cache? A: It caches the result of the configuration phase (the task graph), so later builds skip evaluating the build scripts. It gives large speed-ups, but it requires tasks and plugins to avoid touching mutable global state at execution time.

Q: compileOnly vs runtimeOnly? A: compileOnly is needed to compile but not at runtime (Lombok, some annotations). runtimeOnly is needed at runtime but not to compile (JDBC drivers, logging implementations).