Gradle

buildscript {} configures the build script itself: it declares repositories {} and dependencies { classpath(...) } that put plugin and helper jars on the classpath the script needs to compile and run.

The plugins {} block must be the first statement (after any buildscript/pluginManagement). Gradle parses it specially and early to resolve plugins. Putting other code before it causes a build failure.

It is a block in settings.gradle(.kts) — not build.gradle — where you centrally declare repositories and version catalogs for the whole build instead of repeating them in each module.

An extension is an object a plugin registers via project.extensions.create("name", Type::class.java). Gradle then exposes a build-script block named after it (e.g. name { ... }) that configures that object.

Extra properties are arbitrary user-defined key/value pairs attached to a Gradle object. You set them with ext { key = value } (Groovy) or by extra (Kotlin) and read them back by name later in the script.

Configuration-block code runs during the configuration phase for every build invocation. doFirst{}/doLast{} are action closures that run only in the execution phase, and only if the task actually executes.

onlyIf {} attaches a predicate evaluated right before the task runs. If it returns false, Gradle skips the task's actions and reports it as SKIPPED. If true (or absent), the task executes normally.

Requested tasks are the names you type on the command line (e.g. gradle build). Executed tasks are those plus all their dependencies, which Gradle computes and runs in dependency order.

whenReady registers a callback that runs once Gradle has finished building the task execution graph for the build, after configuration but before any task executes.

gradle init is a built-in task from the build-init plugin that scaffolds a new Gradle project: it generates build/settings scripts, a sample source layout, and the Gradle wrapper, prompting you (or via flags) for project type, DSL, and test framework.

implementation is a declaration bucket — isCanBeResolved is false — so it has no resolution result. Resolve compileClasspath or runtimeClasspath, which extend from it.

The dependencies {} block is where you declare a module's dependencies. Inside it you call a configuration name like implementation(...) with the dependency coordinates (group:name:version) to attach a dependency to that configuration.

testImplementation adds a dependency to the test compile + runtime classpath (e.g. JUnit, Mockito). testRuntimeOnly adds it only to the test runtime classpath (e.g. the JUnit Platform launcher engine). Test classpaths also extend the main ones.

Attach an exclude block to that one dependency, naming the unwanted artifact by group and/or module. Only that dependency's transitive graph is affected.

It's the shorthand for a module's coordinates: group (org), name (artifact), version. You declare it inside a configuration, e.g. implementation("org.apache.commons:commons-lang3:3.14.0").

apply false adds the plugin to the build's classpath and resolves its version, but does NOT apply (activate) it to the root project. Subprojects can then apply it by id with no version.

apply(plugin = "...") is the old imperative way to apply a plugin by ID anywhere in the build script. The modern plugins {} DSL is a declarative block at the top that Gradle understands ahead of time.

The plugins {} block is the declarative way to apply Gradle plugins. Use id("...") for a plugin, adding version "..." for community plugins. Core plugins like java need no version.

Use id("com.example.foo") version "1.2.3" inside plugins {}. Gradle resolves the plugin from the Gradle Plugin Portal (or repositories declared in settings' pluginManagement) by looking up its marker artifact.

The base plugin adds 'assemble' (build all artifacts), 'check' (run all verification like tests), 'build' (assemble + check together), and 'clean' (delete the build directory).

Gradle automatically substitutes the published module coordinates with the local included build's project. Instead of downloading the artifact from a repository, it builds and uses the local source.

A composite build combines otherwise independent Gradle builds into one. You wire it by adding includeBuild('../other-build') to settings.gradle.kts; Gradle then treats the included build as part of the current build.

The plugin build must apply the java-gradle-plugin plugin and declare the plugin id and implementationClass in a gradlePlugin { plugins { register(...) } } block. That generates the marker the consumer's id resolves against.

Prefix the task path with the included build's name: ./gradlew :includedBuildName:some:task. The leading segment is the build name (its directory name unless overridden), not a project in the root build.

Add a project dependency in the consumer's build file, e.g. implementation(project(":lib")). Gradle builds :lib first and puts its compiled output and dependencies on the consumer's classpath.

A cacheable task can store its outputs in the build cache and restore them later instead of re-running. It needs the @CacheableTask annotation and fully declared inputs and outputs.

Set org.gradle.caching=true in the project's gradle.properties so it is on for every build and every developer, or pass --build-cache on a single command to enable it just for that run.

FROM-CACHE means Gradle restored the task's outputs from the build cache instead of running it. UP-TO-DATE means outputs were already on disk and unchanged. Executed means the task actually ran.

By default the local build cache lives in ~/.gradle/caches/build-cache-1. It stores the outputs of cacheable tasks keyed by a hash, so a later build can reuse them instead of re-running the task.

In settings.gradle(.kts), inside the buildCache { remote<HttpBuildCache> { ... } } block. It takes effect very early — during settings evaluation, before any project is configured — because the cache must be ready before tasks run.

Continuous build runs gradle -t <task> (or --continuous). Gradle stays alive, watches the task inputs, and automatically re-runs the requested tasks whenever a relevant input file changes, instead of exiting after one run.

gradle dependencies prints the resolved dependency trees for each configuration. Use --configuration <name> (e.g. runtimeClasspath) to limit the output to one configuration instead of dumping every one.

Use -x or --exclude-task with the task name, e.g. gradle build -x test. Gradle removes that task — and any task needed only by it — from the execution graph for this run.

Use --quiet (-q) for less output, --info (-i) for more, and --debug (-d) for everything. They set the log level; only one applies, with --debug the most verbose and --quiet the least.

-P sets a Gradle project property, read via project.property("name"). -D sets a JVM system property, read via System.getProperty("name"). -P is Gradle-specific; -D is standard JVM.

The Worker API lets a task hand units of work to Gradle's worker pool so they run in parallel. You inject WorkerExecutor, define a WorkAction, and submit work to a queue. It enables parallelism and isolation that a plain task action can't get.

convention(...) supplies a default value used only if nobody calls set(...). set(...) is an explicit assignment that overrides any convention. So convention = fallback default, set = the actual chosen value.

An extension is an object added to a project that exposes a configuration block (DSL). A plugin registers it with project.extensions.create("myExt", MyExtension::class.java), then users configure it via a myExt { ... } block.

It's a Gradle collection of objects each identified by a unique name. Plugins expose one so users can declare multiple named instances in a DSL block, like sourceSets or configurations.

Use task.greeting.set(extension.greeting). This wires the task's Property to the extension's Property lazily, so the value is read later (at execution), not while configuring.

Add jacoco to the plugins {} block. Gradle then adds a jacocoTestReport task and a jacoco {} extension, and instruments your tests so coverage data is collected when you run test.

GradleRunner is the TestKit entry point that runs a real Gradle build against a temporary project directory. You create it, point it at a project dir, pass arguments, and call build() to execute and inspect the result.

It's a JaCoCo plugin task that checks coverage against rules you define in violationRules. If coverage is below the configured minimum, the task fails, which fails the build.

The JUnit BOM is a Bill of Materials that declares one consistent version for all JUnit modules (Jupiter, Platform, Vintage). Importing it with platform(...) lets you list JUnit dependencies without versions, so they all align.

Call useJUnitPlatform() on the test task. By default Gradle uses the JUnit 4 runner, so you must opt into the JUnit Platform for Jupiter tests to be detected and executed.

Gradle assembles the name as [baseName]-[appendix]-[version]-[classifier].[extension]. So baseName 'app', version '1.0', classifier 'sources' produces app-1.0-sources.jar. Empty parts are skipped along with their dash.

Inside publishing { publications { ... } }, on the publication, call artifact(tasks.named("fatJar")). That single line adds the fat JAR as an extra file on that publication's coordinates.

Inside the java { } block call withSourcesJar() and withJavadocJar(). Gradle registers sourcesJar and javadocJar tasks and attaches them to the java component, so they publish automatically.

It's a JSON file (module.module) Gradle publishes alongside the POM. It describes a module's variants, their dependencies, and attributes — richer info than a flat POM can express, so Gradle can pick the right variant when resolving.

A SoftwareComponent describes what a project produces for publication (its artifacts and dependencies). The MavenPublication's from(components.java) reads a component to populate the artifacts and POM/metadata that get published.

The daemon is a long-lived background JVM that Gradle reuses across builds to avoid startup cost. Disable it for one build with --no-daemon, or permanently via org.gradle.daemon=false in gradle.properties.

It sets how long (in milliseconds) an idle Gradle daemon stays alive before shutting itself down. The default is 10800000 ms — three hours.

org.gradle.jvmargs is a Gradle property that passes JVM flags (like -Xmx) to the build daemon's JVM. You set it in gradle.properties, usually in the project root or the user's ~/.gradle directory.

The daemon JVM is the JVM that actually runs Gradle itself. Java toolchains pick a (possibly different) JDK to compile and run your project's code. They are configured separately and can be different versions.

Two main spots: the project root (<project>/gradle.properties), checked into the repo for shared settings, and GRADLE_USER_HOME (~/.gradle/gradle.properties), a per-developer/machine file for local or secret values.

Applying eclipse adds tasks that generate Eclipse metadata files: .project and .classpath (and .settings). You run ./gradlew eclipse to create them and cleanEclipse to remove them.

Sync runs the build's initialization and configuration phases through Gradle's Tooling API to discover projects, tasks, dependencies and source sets, then feeds that model to the IDE. It does not run your tasks, but it does execute build-script code.

Gradle has three console modes. plain gives flat text with no colors or progress bar. rich forces colors and the animated progress bar. auto (the default) picks rich when attached to a terminal, plain otherwise.

-q/--quiet shows only errors and important messages; -i/--info adds informational detail like up-to-date reasons; -d/--debug shows everything including internals and timestamps. No flag means the default LIFECYCLE level.

The default level is LIFECYCLE. It shows task execution progress, the BUILD SUCCESSFUL/FAILED line, and user-facing messages — but hides INFO and DEBUG detail to keep output concise.

android { } is the configuration extension AGP registers when you apply it. Inside it you set things like compileSdk, namespace, and defaultConfig. It configures AGP's tasks; without AGP applied, the block does not exist.

AGP is a Gradle plugin you apply with com.android.application (or com.android.library). Gradle is the generic build engine; AGP teaches Gradle how to build an Android app — compile, package an APK/AAB, and run Android-specific tasks.

Build types are AGP configurations for how an app is built. AGP ships two by default: debug (debuggable, no shrinking) and release (optimizable, shrinkable, signable for distribution).

Jib is a Gradle plugin (com.google.cloud.tools.jib) that builds an OCI/Docker image for a JVM app directly from your build, with no Dockerfile and no Docker daemon. You run a task like jib or jibDockerBuild.

Apply the org.jetbrains.kotlin.multiplatform plugin, then open a kotlin { } block and call target functions like jvm(), js(), and iosX64(). Each call adds a platform the module compiles for.