ابزار Build: Maven در برابر GradleBuild Tools: Maven vs Gradle

Let's get one thing straight up front: a real Java project is not just a handful of .java files. You depend on dozens of external libraries, you must compile the code, run the tests, bundle up resources, produce a final artifact (a JAR or WAR), and maybe publish it somewhere. If you tried to do all of this by hand with javac and java, you'd lose your mind on even a small project. A build tool is the assistant that automates all this repetitive, intricate work. In this chapter you won't just memorize commands — you'll actually understand the philosophy behind each of the two tools (Maven and Gradle), what pain each one cures, and how to compare them in a senior interview.

Part 0 — a few words you must feel before we start

Before we dive into detail, a few terms recur throughout this chapter. Let me plant them in your mind now.

• Artifact: the output a build produces or consumes — usually a JAR (a Java library), a WAR (a web app), or a POM. Each artifact is identified by the triple groupId:artifactId:version, like the name, surname, and national ID of a package.
• Dependency: an external library your project needs, like Jackson for JSON or JUnit for testing.
• Repository: a warehouse where artifacts are stored. Java's central one is Maven Central; both Maven and Gradle download dependencies from it.
• Declarative vs imperative: "declarative" means you state what you want and the tool decides how (like ordering from a menu). "Imperative" means you spell out the how, step by step (like writing a recipe). This distinction is the very heart of the difference between Maven and Gradle.

What is a build tool, and why does it even exist?

Let's see the problem precisely. The lifecycle of a piece of Java code on its way to becoming a product needs all of this:

• Resolve and download dependencies: figure out which libraries at which versions the project needs, and fetch them from a repository.
• Compile: turn .java into .class.
• Run tests: unit and integration tests.
• Package: build a JAR/WAR from classes and resources.
• Publish/deploy: push the artifact to a repository so others can use it.

A build tool does all of this from one config file and a couple of short commands. More important than convenience, a build tool brings reproducibility: every developer and every CI server, given the same config, produces the same output. The infamous "but it worked on my machine" is exactly the pain a build tool cures.

Maven: the "convention over configuration" philosophy

Maven's founding principle is "Convention over Configuration." It ships with sensible defaults, and if you follow them, there's almost nothing left to configure. The folder structure, for instance, is conventional:

my-app/
├── pom.xml
└── src/
    ├── main/
    │   ├── java/          ← main code goes here
    │   └── resources/     ← resource files (config, properties)
    └── test/
        ├── java/          ← test code goes here
        └── resources/

You never tell Maven "where the code is" because the convention is that it lives in src/main/java. That one decision erases thousands of lines of configuration.

The POM file: the project's identity card

The simplest possible POM looks like this:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <!-- this project's identity triple (coordinates) -->
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.release>21</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.18.2</version>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>5.11.4</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Three things to feel here: coordinates (the groupId:artifactId:version that identifies the project), properties (reusable variables like the Java version), and dependencies (the shopping list). That the POM is written in XML is both a strength (standard, schema-validatable, machine-readable) and Maven's famous weakness (verbose and long-winded).

Lifecycle, phase, and goal — three words everyone conflates

Here is Maven's single most important concept, and most people leave it half-understood. Three terms you must keep sharply distinct:

Maven has three built-in lifecycles: clean (cleanup), default (the main build), and site (documentation). The most important is default. Its main phases, in order:

The key point: when you run mvn package, Maven also runs every phase before package — that means validate, compile, and test all run too. This sequential, cumulative nature is the essence of the Maven model.

mvn clean          # only the clean phase: deletes the target folder
mvn compile        # validate → compile
mvn test           # validate → compile → test
mvn package        # ... → test → package (the JAR is built)
mvn verify         # ... → package → verify
mvn install        # ... → verify → install (installed into ~/.m2)

# common combo: clean first, then a full build and install
mvn clean install

Dependency management in Maven

Now we reach the heart of the matter — where build tools truly shine: dependency management. They must solve three problems: scope, transitivity, and version conflict.

Scope: where is each dependency needed?

A subtle point: provided means "this dependency is needed at compile time, but the runtime environment (say an app server, or the JDK itself) supplies it, so don't put it inside my JAR/WAR." The classic example is the Servlet API, supplied by a server like Tomcat.

Transitive dependencies

To see this tree, use this goal:

mvn dependency:tree

The output looks something like this — you can see spring-boot-starter-web dragged a lot of other things along:

com.example:my-app:jar:1.0.0
+- org.springframework.boot:spring-boot-starter-web:jar:3.4.1:compile
|  +- org.springframework.boot:spring-boot-starter:jar:3.4.1:compile
|  +- org.springframework:spring-web:jar:6.2.1:compile
|  \- com.fasterxml.jackson.core:jackson-databind:jar:2.18.2:compile
\- org.junit.jupiter:junit-jupiter:jar:5.11.4:test

Version conflict resolution: the "nearest-wins" rule

Now the serious problem: what if A needs version 1.0 of library X, and B needs version 2.0 of the same X? A classpath cannot hold two versions of one class. Maven must pick one.

A concrete example. Suppose you have this tree:

my-app
+- A → X:1.0        (depth 2)
\- B
   \- C
      \- X:2.0      (depth 4)

Here X:1.0 wins because it's closer to the root (depth 2 vs 4) — even though it's the lower version! If that behavior causes trouble, you have two tools:

<!-- Option 1: exclusion — remove a transitive dependency from under B -->
<dependency>
    <groupId>com.example</groupId>
    <artifactId>B</artifactId>
    <version>1.0.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.example</groupId>
            <artifactId>X</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!-- Option 2, better: declare the version directly at depth 1 so it wins -->
<dependency>
    <groupId>com.example</groupId>
    <artifactId>X</artifactId>
    <version>2.0.0</version>
</dependency>

dependencyManagement and BOM

The dependencyManagement section declares a version but does not add the dependency to the classpath; it only says "if and wherever this library is used, take this version of it":

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.18.2</version>   <!-- version set in one place -->
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <!-- no version! it comes from dependencyManagement -->
    </dependency>
</dependencies>

And to import a ready-made BOM (like Spring Boot's, which harmonizes dozens of library versions), you use scope=import:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.4.1</version>
            <type>pom</type>
            <scope>import</scope>   <!-- import Spring's whole version list -->
        </dependency>
    </dependencies>
</dependencyManagement>

Multi-module projects and the reactor

Real projects usually consist of several parts: a core module, an api, a web. Maven manages this with a parent/child structure.

<!-- parent pom.xml -->
<project ...>
    <groupId>com.example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
    <packaging>pom</packaging>   <!-- note: pom, not jar -->

    <modules>
        <module>core</module>
        <module>web</module>
    </modules>
</project>

When you run mvn install from the parent folder, Maven activates something called the reactor.

Gradle: the "programmable build" philosophy

Now we reach the rival. If Maven was a "standardized official form," Gradle is something else entirely.

Instead of XML, Gradle uses a DSL (domain-specific language) that is actually real Groovy or Kotlin code. That means your build file is a program, not just data. The build file is named build.gradle (for Groovy) or build.gradle.kts (for Kotlin).

Let's see that same earlier project, this time in Gradle (Kotlin DSL):

// build.gradle.kts
plugins {
    java
}

group = "com.example"
version = "1.0.0"

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
}

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

tasks.test {
    useJUnitPlatform()
}

Two things jump out immediately: first, it's far shorter than the equivalent XML. Second, dependencies are written as a compact "group:artifact:version" string. And instead of <scope>, here we have configurations: implementation and testImplementation.

Task: Gradle's unit of work

In Maven the unit of work was the "phase"; in Gradle the unit of work is the task. Everything Gradle does — compile, test, build a JAR — is a task.

You can define your own custom task — that's the "programmability" Maven lacked:

tasks.register("hello") {
    doLast {
        println("Hello from a custom Gradle task!")
    }
}

// a task that depends on another task
tasks.register("deployDocs") {
    dependsOn("build")     // run build first, then this
    doLast {
        println("Deploying documentation...")
    }
}

gradle tasks          # list all available tasks
gradle build          # full build (compile + test + package)
gradle hello          # run our custom task
gradle deployDocs      # build first, then deployDocs

Two vital phases: configuration vs execution

Here is Gradle's most important concept, the one that turns you from a surface user into a pro. Every Gradle run actually has two distinct phases (three with initialization, but we focus on these two):

This example makes the difference clear:

tasks.register("demo") {
    // this line runs in the CONFIGURATION phase — on every gradle run, always
    println("Configuring the task")

    doLast {
        // this line runs only in the EXECUTION phase — only when demo actually runs
        println("Executing the task")
    }
}

If you run gradle help (which does not run the demo task), "Configuring the task" still prints, but "Executing the task" does not. This trap is the single biggest source of slowness in bad builds.

Why Gradle is fast: four speed tools

Gradle's fame rests on its speed. That speed comes from four mechanisms you must all know.

1. Incremental build

Run gradle build twice in a row and, the second time, you'll see most tasks marked UP-TO-DATE — Gradle detected nothing changed and did nothing. This input/output comparison is the core of Gradle's speed.

2. Build cache

# gradle.properties — enable the build cache
org.gradle.caching=true

3. Daemon

4. Configuration cache (the newest and most important)

# gradle.properties
org.gradle.configuration-cache=true
org.gradle.parallel=true

Version catalog: Gradle's answer to the BOM

Gradle also has a way to centralize versions: the libs.versions.toml file.

# gradle/libs.versions.toml
[versions]
jackson = "2.18.2"
junit = "5.11.4"

[libraries]
jackson-databind = { module = "com.fasterxml.jackson.core:jackson-databind", version.ref = "jackson" }
junit-jupiter = { module = "org.junit.jupiter:junit-jupiter", version.ref = "junit" }

// and in build.gradle.kts:
dependencies {
    implementation(libs.jackson.databind)
    testImplementation(libs.junit.jupiter)
}

The advantage: versions are managed in one place, typed, and with auto-completion in the IDE.

When to pick which?

Now that you understand both, let's compare honestly. Neither is "better" absolutely; each fits a situation.

Reproducible builds

An important goal both tools pursue: reproducibility. It means if you build the same code today, six months from now, and on a different machine, you get byte-for-byte the same artifact.

Pitfalls and best practices

Let's gather the top traps in one place — the ones that bite in real code or interviews:

• Getting caught by "highest version" vs "nearest version": Maven picks nearest, Gradle picks highest. If you don't know this, version conflicts will confuse you.
• Heavy work in Gradle's configuration phase: any top-level code or code in a task's body (not doLast) runs on every invocation. Put real work in doLast.
• Forgetting dependencyManagement/BOM: without centrally locking versions, each module can pull a different version and you land in "dependency hell."
• Using old compile instead of implementation in Gradle: implementation hides the dependency from consumers, making compiles faster and modules more independent.
• Floating versions (+): they destroy reproducibility. Always pin versions.
• Skipping tests as a habit: -DskipTests is sometimes needed, but as a habit it bypasses the lifecycle's built-in safety.

Best practices: manage versions centrally (BOM or version catalog); regularly inspect dependency:tree or gradle dependencies; for a new Gradle project, enable Kotlin DSL and the configuration cache; commit the Wrapper (mvnw or gradlew) so everyone builds with the same tool version.

Interview Questions

Now it's time to test everything with real senior-interview questions. Try answering each yourself first, then open the answer.