Build Tools: Maven & Gradle

<!-- pom.xml -- Maven declares a dependency, and Maven handles downloading it and its own transitive dependencies -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.2</version>
</dependency>

Common follow-ups: What's the difference between a build tool and a package manager, or are they the same thing in the Java ecosystem?;How do build tools resolve version conflicts when two dependencies require different versions of the same transitive library?

# Running 'mvn package' automatically runs validate, compile, and test first
mvn package

# Running 'mvn install' runs everything through package first, then installs to ~/.m2
mvn install

# Skip tests during a phase (use sparingly)
mvn package -DskipTests

Common follow-ups: What's the difference between skipping tests with -DskipTests versus -Dmaven.test.skip=true?;How would you bind a custom plugin goal to run during a specific lifecycle phase?

<!-- Forcing a specific version regardless of transitive resolution -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.15.2</version>  <!-- forces this version project-wide -->
        </dependency>
    </dependencies>
</dependencyManagement>

# Diagnose the actual resolved dependency tree
mvn dependency:tree -Dverbose

Common follow-ups: How does Gradle's dependency resolution strategy (highest version wins by default) differ from Maven's nearest-wins approach?;What's the practical difference between <exclusions> and <dependencyManagement> for resolving a conflict?

// build.gradle.kts (Kotlin DSL)
plugins {
    id("java")
}

dependencies {
    implementation("com.fasterxml.jackson.core:jackson-databind:2.15.2")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

tasks.test {
    useJUnitPlatform()
}

Common follow-ups: What are the trade-offs of Gradle's flexibility potentially leading to inconsistent, hard-to-maintain build scripts across different projects?;Why did Gradle introduce the Kotlin DSL as an alternative to the original Groovy DSL?

// gradle.properties -- enabling build caching
org.gradle.caching=true
org.gradle.parallel=true

// A task run twice with no source changes:
// First run: ":compileJava" executes normally
// Second run: ":compileJava UP-TO-DATE" -- skipped entirely, saving time

Common follow-ups: What are the correctness risks of build caching if a task's inputs/outputs aren't declared completely and accurately?;How does Gradle's daemon process further contribute to faster subsequent build invocations?

<dependencies>
    <dependency>
        <groupId>jakarta.servlet</groupId>
        <artifactId>jakarta.servlet-api</artifactId>
        <version>6.0.0</version>
        <scope>provided</scope>  <!-- servlet container already provides this at runtime -->
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.10.0</version>
        <scope>test</scope>  <!-- only needed for running tests, excluded from the deployable WAR -->
    </dependency>
</dependencies>

Common follow-ups: What happens if you incorrectly mark a scope as provided when the runtime environment actually doesn't supply that dependency?;How does Gradle's equivalent configuration (implementation, compileOnly, runtimeOnly, testImplementation) map to Maven's scopes?

<!-- parent pom.xml -->
<packaging>pom</packaging>
<modules>
    <module>core</module>
    <module>api</module>
    <module>web</module>
</modules>

<!-- web/pom.xml declares a dependency on the sibling module -->
<dependency>
    <groupId>com.example</groupId>
    <artifactId>core</artifactId>
    <version>${project.version}</version>
</dependency>

Common follow-ups: How does Gradle's project isolation and configuration-on-demand feature improve multi-module build performance further?;What are the trade-offs of a multi-module monorepo versus splitting into entirely separate repositories?

<dependency>
    <groupId>com.example</groupId>
    <artifactId>some-library</artifactId>
    <version>1.0.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!-- Now explicitly declare the desired, patched version yourself -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.3</version>  <!-- patched for a known CVE -->
</dependency>

Common follow-ups: How would you use `mvn dependency:tree` to identify exactly which parent dependency is pulling in the problematic transitive version?;What's the equivalent mechanism in Gradle for excluding a specific transitive dependency?

// Custom Gradle task, defined directly in build.gradle.kts
abstract class GenerateVersionFile : DefaultTask() {
    @TaskAction
    fun generate() {
        val versionFile = File(project.buildDir, "version.txt")
        versionFile.writeText(project.version.toString())
    }
}

tasks.register<GenerateVersionFile>("generateVersionFile")
tasks.named("build") { dependsOn("generateVersionFile") }

Common follow-ups: What's the process for publishing a custom Maven plugin so other projects/teams can reuse it?;How does Gradle's task dependency graph (dependsOn, mustRunAfter) let you control custom task execution order relative to built-in tasks?

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.2.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- No version needed -- inherited from the imported BOM -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Common follow-ups: How would an organization create and publish its own internal BOM to standardize dependency versions across many internal projects?;What's Gradle's equivalent mechanism for importing a BOM (the platform() function)?