Introdução ao Gradle para Java

Gradle é uma ferramenta de automação de build para a JVM (e além) que compila seu código, executa seus testes, gerencia suas dependências e empacota o resultado — tudo controlado por um script de build que você escreve em Groovy ou Kotlin. Onde o Maven descreve um projeto com XML fixo, o Gradle o descreve com código: um script de build que configura um grafo de tarefas. Essa mudança para um modelo programável, aliada a um cache de build incremental que ignora o trabalho já realizado, é o motivo pelo qual o Gradle potencializa o Android e muitos projetos Java de grande porte.

Gradle vs. Maven

Ambas as ferramentas resolvem o mesmo problema — builds repetíveis com dependências gerenciadas —, mas fazem escolhas diferentes. Se você já conhece o Maven, este é o mapeamento:

Aspecto	Maven	Gradle
Arquivo de build	`pom.xml` (XML)	`build.gradle` (Groovy) ou `build.gradle.kts` (Kotlin)
Modelo	Fases do ciclo de vida fixas	Grafo de tarefas configurável (um DAG)
Extensibilidade	Plugins, vinculados às fases	Plugins e tarefas ad-hoc escritas inline
Builds incrementais	Limitado	Nativo: verificações up-to-date + cache de build
Wrapper	opcional	`gradlew` é o padrão — fixa a versão do Gradle
Verbosidade	Mais boilerplate	Conciso, mas mais "mágica" para aprender

Nenhum é estritamente melhor. A rigidez do Maven torna os builds previsíveis; a flexibilidade do Gradle torna builds complexos expressáveis. Esta parte ensina Gradle; a introdução ao Maven cobre o outro lado.

Um script de build Java mínimo

Um projeto Java com Gradle é composto por um build.gradle e um layout de código-fonte convencional (src/main/java, src/test/java). Aplicar o plugin embutido java é o que ensina ao Gradle como compilar, testar e gerar o jar:

plugins {
    id 'java'
}

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

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.guava:guava:33.0.0-jre'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

O DSL Kotlin (build.gradle.kts) expressa a mesma coisa com acessores type-safe:

plugins {
    java
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

As tarefas são a unidade de trabalho

Tudo o que o Gradle faz é uma tarefa — compileJava, test, jar, build. As tarefas declaram dependências em outras tarefas, formando um grafo acíclico dirigido (DAG). Quando você executa gradle build, o Gradle percorre esse grafo e executa cada pré-requisito exatamente uma vez, em ordem. Você também pode definir as suas próprias:

task hello {
    doLast {
        println 'Hello from a custom Gradle task'
    }
}

task release {
    dependsOn 'build', 'hello'
}

O plugin java monta um grafo padrão para você: classes depende de compileJava e processResources; jar depende de classes; test depende de classes e compileTestJava; e build depende de jar e test. Solicitar build executa todas elas na ordem de dependência.

O wrapper e a linha de comando

O Gradle Wrapper (gradlew / gradlew.bat) é um script versionado no repositório que baixa e executa a versão exata do Gradle que o projeto espera, para que os colaboradores não precisem ter o Gradle instalado globalmente:

./gradlew build          # compile, test, and package
./gradlew test           # run tests only
./gradlew clean build    # wipe outputs, then rebuild from scratch
./gradlew tasks          # list available tasks
./gradlew dependencies   # print the resolved dependency tree

Usar ./gradlew em vez do gradle do sistema é o padrão recomendado — torna o build reproduzível entre máquinas e em ambientes de CI.

Um exemplo prático: um grafo de tarefas, resolvido como o Gradle faz

Não há Gradle no executor desta página, portanto, em vez de um build real, modelamos o motor central do Gradle em Java puro: um grafo de tarefas com dependências, resolvido em uma ordem de execução com uma ordenação topológica — exatamente o que o Gradle faz quando você digita gradle build. A segunda passagem mostra como tarefas up-to-date são ignoradas, que é o truque de build incremental do Gradle.

java— editable, runs on the server

import java.util.*;

public class GradleIntroDemo {
  // A tiny stand-in for Gradle's directed acyclic graph of tasks.
  // Each task names the tasks it depends on; Gradle runs dependencies first.
  static final Map<String, List<String>> tasks = new LinkedHashMap<>();

static void task(String name, String... dependsOn) {
    tasks.put(name, Arrays.asList(dependsOn));
  }

// Resolve the execution order with a depth-first topological sort,
  // exactly how Gradle decides what to run before what.
  static void resolve(String name, Set<String> done, List<String> order) {
    if (done.contains(name)) return;          // already scheduled: run once
    for (String dep : tasks.getOrDefault(name, List.of())) {
      resolve(dep, done, order);              // dependencies first
    }
    done.add(name);
    order.add(name);
  }

public static void main(String[] args) {
    // The lifecycle of the Gradle 'java' plugin, modelled as a task graph.
    task("compileJava");
    task("processResources");
    task("classes", "compileJava", "processResources");
    task("jar", "classes");
    task("compileTestJava", "classes");
    task("test", "classes", "compileTestJava");
    task("build", "jar", "test");

System.out.println("declared tasks : " + tasks.size());

// Ask for 'build' and let the graph decide the order, like 'gradle build'.
    List<String> order = new ArrayList<>();
    resolve("build", new HashSet<>(), order);
    System.out.println("gradle build ->");
    for (int i = 0; i < order.size(); i++) {
      System.out.println("  " + (i + 1) + ". " + order.get(i));
    }

// Incremental builds: a task with up-to-date inputs is SKIPPED.
    Set<String> upToDate = Set.of("compileJava", "processResources", "classes");
    System.out.print("second run     :");
    int executed = 0;
    for (String t : order) {
      if (upToDate.contains(t)) {
        System.out.print(" " + t + "(UP-TO-DATE)");
      } else {
        System.out.print(" " + t + "(EXEC)");
        executed++;
      }
    }
    System.out.println();
    System.out.println("tasks executed : " + executed + " of " + order.size());
  }
}

O que extrair da execução:

O build declara 7 tarefas, mas você nunca especifica uma ordem manualmente — você solicita build e o grafo calcula o restante. Essa inversão (declare dependências, deixe a ferramenta ordená-las) é o coração do modelo de tarefas do Gradle.
A ordem resolvida imprime compileJava e processResources primeiro, depois classes, jar, compileTestJava, test e, por fim, build. Uma tarefa só é executada após todas as tarefas das quais depende, razão pela qual a compilação precede o empacotamento e os testes precedem build.
classes é alcançado por dois caminhos (via jar e via test), mas aparece uma vez na ordem — o conjunto done garante que cada tarefa seja executada uma única vez, assim como o Gradle nunca recompila as mesmas fontes duas vezes em uma invocação.
Na segunda execução, as três tarefas marcadas como up-to-date exibem (UP-TO-DATE) e não são contadas; apenas jar, compileTestJava, test e build mostram (EXEC). Este é o build incremental do Gradle: tarefas cujas entradas não mudaram são ignoradas.
A linha final reporta 4 of 7 tarefas executadas. Ignorar o trabalho não alterado é exatamente o motivo pelo qual um segundo gradle build é muito mais rápido que o primeiro, e por que o cache de build importa em projetos grandes.

O que o restante desta parte cobre

Escrever scripts build.gradle reais, declarar e resolver dependências do Maven Central, aplicar e configurar plugins, definir tarefas personalizadas e usar o wrapper em CI. O próximo capítulo, Construindo um projeto Java com Gradle, configura um projeto Java completo com Gradle a partir de um diretório vazio.

Prática

Quando você executa 'gradle build', como o Gradle decide a ordem em que tarefas como compileJava, test e jar são executadas?

Ele percorre o grafo de tarefas, executando cada tarefa somente após as tarefas das quais ela depende, de modo que as dependências são resolvidas em uma ordem correta automaticamenteEle executa as tarefas em ordem alfabética pelo nome, razão pela qual compileJava ocorre antes de testEle executa todas as tarefas na ordem exata em que estão escritas no build.gradle, de cima para baixoEle executa todas as tarefas em paralelo sem nenhuma ordem, pois os builds do Gradle são totalmente concorrentes