gradle-build

Build a Gradle project

TLDR

Build the project

$ gradle build

Perform a clean build

$ gradle clean build

Build the project while skipping tests

$ gradle build [[-x|--exclude-task]] test

Build with more detailed logging

$ gradle build [[-i|--info]]

gradle [GLOBAL_OPTIONS] build [TASK_OPTIONS]
GLOBAL_OPTIONS: Options that apply to the entire Gradle invocation.
TASK_OPTIONS: Options specific to the build task or tasks it depends on, often passed as system properties or project properties (e.g., -PmyProp=value).

PARAMETERS

--build-file , -b
Specifies the build file. Defaults to build.gradle or build.gradle.kts in the current directory.

--project-dir

, -p
    Specifies the start directory for Gradle to search for the build script.

--console
    Sets the console output mode. Modes include plain, auto, rich.

--debug, -d
    Log in debug mode (includes normal, info, lifecycle, and debug messages).

--info, -i
    Log in info mode (includes normal, info, and lifecycle messages).

--stacktrace, -s
    Print out the stacktrace for all exceptions.

--full-stacktrace, -S
    Print out the full stacktrace for all exceptions.

--rerun-tasks
    Forces all tasks to be re-executed, ignoring up-to-date checks.

--refresh-dependencies
    Refreshes external dependencies (causes all dependencies to be resolved again).

--no-daemon
    Do not use the Gradle daemon to run the build. The daemon typically speeds up subsequent builds.

--parallel
    Build projects in parallel. Can significantly speed up multi-project builds.

-x
    Exclude tasks from the build. For example, gradle build -x test would run the build without executing the test task.

DESCRIPTION

The "gradle-build" command, typically invoked as gradle build, is a fundamental command in the Gradle build automation tool used to compile, test, and package a software project. It initiates the execution of the 'build' lifecycle task, which itself depends on other standard tasks such as assemble (for compiling and packaging), check (for running tests and static analysis), and potentially others defined in the project's build.gradle or build.gradle.kts file.

This command is central to the development workflow, allowing developers to ensure their code compiles, passes all defined tests, and produces distributable artifacts like JARs, WARs, or other packages. Gradle's declarative DSL (Domain Specific Language), often written in Groovy or Kotlin, allows for highly customizable and flexible build processes. When gradle build is executed, Gradle resolves dependencies, compiles source code, runs unit and integration tests, and bundles the output, providing comprehensive feedback on the build's success or failure.

CAVEATS

Gradle Installation: The gradle executable must be installed on your system and available in the system's PATH. Alternatively, you can use the Gradle Wrapper (gradlew or gradlew.bat) which bundles the necessary Gradle version.
Build Script Presence: A build.gradle or build.gradle.kts file must exist in the current directory or a parent directory for Gradle to identify the project.
JDK Requirement: Gradle projects typically require a Java Development Kit (JDK) to be installed and configured correctly (via JAVA_HOME environment variable) for compilation and execution.
Dependency Management: External dependencies declared in the build script must be resolvable from configured repositories (e.g., Maven Central). Network connectivity is often required for the initial download of these dependencies.

THE BUILD LIFECYCLE

The build task is a composite task that represents a complete build lifecycle. It depends on check (which runs tests) and assemble (which compiles and packages artifacts). Understanding these dependencies helps in customizing the build process, for example, by excluding certain sub-tasks or injecting custom logic at different phases.

OUTPUT AND REPORTING

Upon successful execution, gradle build typically outputs messages indicating the completion of various tasks and ultimately a `BUILD SUCCESSFUL` message. If tests are run, it might also generate HTML reports in the project's build/reports/tests directory. In case of failure, detailed error messages and stacktraces (especially with --stacktrace) are provided to help diagnose issues.

CUSTOMIZING THE BUILD TASK

The behavior of the build task, and the tasks it depends on, can be extensively customized within the build.gradle or build.gradle.kts file. This includes configuring compiler options, test execution parameters, artifact naming conventions, and adding custom tasks or dependencies between existing ones.

HISTORY

Gradle emerged in 2007, aiming to combine the best features of Apache Ant and Apache Maven. It introduced a Groovy-based Domain Specific Language (DSL) for build scripts, offering greater flexibility and expressiveness compared to XML-based configurations. Key milestones include the introduction of the Gradle Daemon for faster incremental builds, robust dependency management, and strong support for multi-project builds. In more recent years, Gradle added official support for a Kotlin DSL, providing a more type-safe and IDE-friendly experience for defining builds. Its focus on performance, incremental builds, and a highly configurable task graph has made it a popular choice for building a wide range of JVM-based applications, mobile apps (Android), and native projects.