Gradle in brief

Why learn Gradle too?

You will meet both tools at work. Many backend teams use Maven; Android projects, many Kotlin projects and some large multi-module builds use Gradle. The ideas are the same (dependencies from Maven Central, a standard layout, test and build steps), so learning the second tool is quick.

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

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

repositories { mavenCentral() }

dependencies {
    implementation("org.postgresql:postgresql:42.7.4")             // example versions
    testImplementation("org.junit.jupiter:junit-jupiter:5.11.3")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

application { mainClass = "com.shop.App" }

tasks.test { useJUnitPlatform() }

Common commands

Dependency configurations

• implementation: needed to compile and run your code (like Maven compile scope).
• testImplementation: only for tests (like Maven test scope).
• runtimeOnly: needed only when running (for example a JDBC driver loaded at run time).
• compileOnly: needed only to compile (for example annotation-only libraries).

Maven versus Gradle

Multi-module builds and the build cache

Larger systems split code into modules (for example api, service, persistence) declared in settings.gradle.kts with include("api", "service"). Gradle builds only the modules that changed and can reuse outputs from earlier builds (the build cache), which is why big Android and backend projects often prefer it. The Gradle daemon, a background process kept warm between builds, also saves start-up time on every command.