Java Essencial: Noções de Gradle e comparação prática com Maven

O que é o Gradle e como ele organiza um projeto

Gradle é uma ferramenta de automação de build que, assim como o Maven, resolve dependências, compila, executa testes e empacota artefatos. A diferença prática é que o Gradle usa um modelo mais flexível e programável para descrever o build (normalmente com DSL em Groovy ou Kotlin), permitindo customizações mais diretas por meio de tarefas (tasks) e configurações.

Em projetos Java, o Gradle costuma ser usado com o plugin java (compilação, testes e empacotamento) e, quando há uma aplicação executável, com o plugin application (tarefa run, definição de classe principal etc.).

Estrutura típica de um projeto Gradle (Java)

Um projeto Gradle pode ser single-module (um único módulo) ou multi-module. A estrutura abaixo é comum em um projeto Java simples:

meu-projeto/  settings.gradle  build.gradle  gradlew  gradlew.bat  gradle/    wrapper/      gradle-wrapper.properties      gradle-wrapper.jar  src/    main/      java/        com/exemplo/App.java      resources/    test/      java/        com/exemplo/AppTest.java      resources/

• build.gradle: define plugins, dependências, repositórios e tarefas/configurações do build.
• settings.gradle: define o nome do projeto e, em multi-módulos, quais subprojetos existem.
• gradlew/gradlew.bat e pasta gradle/wrapper: Gradle Wrapper, permite rodar o build com uma versão do Gradle “fixa” sem exigir instalação global.
• src/main/java, src/test/java: convenções de diretórios (semelhantes às do Maven).

Arquivo settings.gradle

Em um projeto simples, normalmente basta definir o nome:

rootProject.name = 'meu-projeto'

Em multi-módulos, você incluiria subprojetos:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

rootProject.name = 'meu-projeto'include 'app', 'core'

Arquivo build.gradle (Java + Application)

Exemplo de build.gradle para um projeto Java com testes e uma classe principal executável:

plugins {    id 'java'    id 'application'}group = 'com.exemplo'version = '1.0.0'repositories {    mavenCentral()}dependencies {    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'}test {    useJUnitPlatform()}application {    // Classe com método main    mainClass = 'com.exemplo.App'}

Pontos importantes:

• plugins: habilitam capacidades (compilar Java, rodar testes, executar aplicação).
• repositories: onde buscar dependências (ex.: Maven Central).
• dependencies: dependências separadas por escopo (ex.: testImplementation para testes).
• test: configura a execução de testes (JUnit 5 exige useJUnitPlatform()).
• application: define a classe principal para a tarefa run.

Dependências no Gradle: como pensar em escopos

No Gradle, você declara dependências em “configurações” (configurations). As mais comuns em projetos Java:

• implementation: dependência necessária para compilar e executar o código principal.
• compileOnly: necessária para compilar, mas não deve ir para runtime (ex.: APIs fornecidas pelo ambiente).
• runtimeOnly: necessária apenas em runtime.
• testImplementation: dependência para compilar/rodar testes.
• testRuntimeOnly: apenas runtime dos testes.

Exemplo com uma lib de logging e um driver em runtime:

dependencies {    implementation 'org.slf4j:slf4j-api:2.0.13'    runtimeOnly 'ch.qos.logback:logback-classic:1.5.6'    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'}

Tarefas essenciais: build, test e run

Gradle organiza o build em tarefas. Algumas tarefas são criadas automaticamente pelos plugins:

• gradle build: compila, roda testes e empacota (gera o JAR). Normalmente executa uma cadeia de tarefas (ex.: compileJava, test, jar).
• gradle test: executa apenas os testes.
• gradle run: executa a aplicação (requer plugin application e mainClass configurada).
• gradle tasks: lista tarefas disponíveis.
• gradle clean: remove diretórios de build.

Observação prática: prefira usar o Wrapper para garantir consistência:

./gradlew build./gradlew test./gradlew run

Passo a passo: criando o Wrapper (se ainda não existir)

Se você tiver o Gradle instalado, pode gerar o Wrapper uma vez:

gradle wrapper

Depois disso, o time usa ./gradlew (Linux/macOS) ou gradlew.bat (Windows).

Comparação prática: quando escolher Maven vs Gradle

Regras práticas de decisão

• Escolha Maven quando: você quer máxima padronização, build mais “declarativo”, pouca customização, e um ecossistema onde o POM é o formato mais comum na organização.
• Escolha Gradle quando: você precisa de customizações frequentes, builds multi-módulos mais sofisticados, performance incremental/caching, ou quer automatizar tarefas além do ciclo padrão com menos atrito.

Migração guiada: de Maven para Gradle (projeto pequeno)

A seguir, um roteiro para migrar um projeto pequeno que já compila, testa e executa via Maven, mantendo comportamento equivalente no Gradle. A ideia é produzir um build Gradle que gere um JAR e rode testes e aplicação de forma similar.

1) Levantar informações do projeto Maven (entrada da migração)

No projeto Maven, identifique no pom.xml:

• groupId, artifactId, version
• Dependências e seus escopos (compile, test, runtime etc.)
• Versão do Java (source/target) se estiver configurada
• Classe principal (se houver execução via plugin)

Exemplo de referência (trecho típico):

<groupId>com.exemplo</groupId><artifactId>meu-projeto</artifactId><version>1.0.0</version><dependencies>  <dependency>    <groupId>org.junit.jupiter</groupId>    <artifactId>junit-jupiter</artifactId>    <version>5.10.2</version>    <scope>test</scope>  </dependency></dependencies>

2) Criar settings.gradle e build.gradle na raiz

Na raiz do projeto (onde está o pom.xml), crie:

// settings.gradlerootProject.name = 'meu-projeto'

Agora crie o build.gradle mapeando coordenadas e dependências:

plugins {    id 'java'    id 'application'}group = 'com.exemplo'version = '1.0.0'repositories {    mavenCentral()}dependencies {    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'}test {    useJUnitPlatform()}application {    mainClass = 'com.exemplo.App'}

3) Garantir a mesma versão de Java (toolchain)

Se o Maven estava fixando uma versão (por exemplo, 17), replique no Gradle com toolchain para consistência entre máquinas:

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

Isso ajuda a evitar “funciona na minha máquina” quando alguém tem outro JDK padrão instalado.

4) Manter a estrutura de diretórios compatível

Se seu projeto Maven já usa:

• src/main/java
• src/main/resources
• src/test/java

Você não precisa mudar nada: o plugin java do Gradle reconhece essa convenção automaticamente.

5) Validar equivalência de comandos (checklist)

Execute os comandos abaixo e compare com o resultado que você obtinha no Maven (compilação, testes, geração de artefato):

• Limpar e buildar: ./gradlew clean build
• Rodar testes: ./gradlew test
• Gerar JAR: ./gradlew jar
• Executar app: ./gradlew run

Artefatos do Gradle ficam em build/ (por padrão), por exemplo:

build/libs/meu-projeto-1.0.0.jar

6) Ajustar empacotamento e execução (se o Maven gerava JAR executável)

Se no Maven você configurava um JAR executável (com Main-Class no manifesto), no Gradle você pode configurar o manifesto do JAR:

jar {    manifest {        attributes 'Main-Class': 'com.exemplo.App'    }}

Assim, você pode executar com:

java -jar build/libs/meu-projeto-1.0.0.jar

Observação: isso gera um JAR executável, mas não necessariamente “fat jar” (com dependências dentro). Se o seu Maven empacotava dependências no mesmo JAR, a migração exige uma estratégia específica (por exemplo, plugin Shadow no Gradle) para manter o comportamento.

7) Migrar dependências do pom.xml para o build.gradle (mapeamento rápido)

Use este mapeamento mental de escopos:

Exemplo: se no Maven havia uma dependência de runtime, migre para:

dependencies {    runtimeOnly 'grupo:artefato:versao'}

8) Remover/conviver com o pom.xml durante a transição

Para uma migração segura:

• Mantenha o pom.xml por alguns commits enquanto valida o Gradle no CI e na equipe.
• Quando o Gradle estiver estável, você pode remover o pom.xml para evitar dupla fonte de verdade.

9) Dica prática: inspecionar o que o Gradle está fazendo

Para entender a cadeia de tarefas e diagnosticar diferenças:

• Listar tarefas: ./gradlew tasks
• Ver dependências resolvidas: ./gradlew dependencies
• Mais detalhes de execução: ./gradlew build --info (ou --debug)