Build Script Basics in Gradle

Introduction

Gradle projects are configured with settings.gradle (which projects exist) and build.gradle (how each project builds). This chapter explains the Groovy DSL blocks you edit daily—plugins, coordinates, repositories, Java toolchain—and how they map to a Kotlin build.gradle.kts file.

Prerequisites

• First Gradle project
• Gradle Wrapper

settings.gradle — Project Tree

Single-project app:

// Project display name
rootProject.name = 'hello-gradle'

Multi-project monorepo:

rootProject.name = 'my-monorepo'
include 'app'
include 'lib:core'

include paths map to folders app/ and lib/core/ with their own build.gradle.

Centralized Repositories (Gradle 7+)

Many teams add this to settings.gradle so all modules share repositories:

FAIL_ON_PROJECT_REPOS forces modules to use the shared list—good for consistency. Learning projects may keep repositories { } only in build.gradle for simplicity.

build.gradle Skeleton (Groovy DSL)

Plugins Block and Versions

plugins {
    id 'java'
    id 'application'
}

Versioned plugins from the portal:

plugins {
    id 'org.springframework.boot' version '3.4.0'
    id 'io.spring.dependency-management' version '1.1.7'
    id 'java'
}

Plugin IDs and versions live in one place—cleaner than legacy buildscript { } blocks.

Coordinates: group, version, archivesBaseName

Published JARs often use:

com.example:hello-gradle:1.0.0-SNAPSHOT

• group — like Maven groupId (com.example)
• version — 1.0.0-SNAPSHOT for dev, 1.0.0 for release
• archivesBaseName (optional) — JAR file prefix; defaults to project folder name

group = 'com.example'
version = '1.0.0-SNAPSHOT'

Java Toolchain vs sourceCompatibility

Preferred in modern builds:

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

Gradle can auto-provision a JDK via toolchains (if configured). Older style still seen:

java {
    sourceCompatibility = JavaVersion.VERSION_21
    targetCompatibility = JavaVersion.VERSION_21
}

This tutorial standard is toolchain + JDK 21.

gradle.properties

Project or user-level flags:

org.gradle.jvmargs=-Xmx2g -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.caching=true

Version shortcuts:

gsonVersion=2.11.0

Used in build.gradle as "$gsonVersion" or findProperty('gsonVersion').

Kotlin DSL (build.gradle.kts)

Same concepts, Kotlin syntax:

Use Groovy for most Java-only learning; use KTS when the team or Android/Kotlin stack standardizes on it.

Mini Example: Print Coordinates Task

tasks.register('showCoords') {
    group = 'help'
    description = 'Print project group and version'
    doLast {
        println "group=$project.group version=$project.version"
    }
}

./gradlew showCoords

Custom tasks are covered in Gradle tasks.

FAQ

settings.gradle vs build.gradle?

Settings = structure (includes). Build = behavior (compile, deps, tasks).

Can I have no settings.gradle?

Gradle creates implicit defaults; real projects always commit settings.gradle.

Plugin not found?

Check pluginManagement repositories and plugin version spelling.

What comes next?

Dependency management.