Gradle sem medo — Parte 2— Visão geral

O Gradle, assim como o Maven, é uma ferramenta de build que auxilia principalmente na construção de um pacote final do sistema garantindo que etapas como testes tenham sido executadas e também ajuda na gestão das dependências com outras bibliotecas que você inclua no seu projeto. Mas o objetivo destes artigos não é explicar o que é o Gradle, mas sim como ele funciona. Então considerarei que você já conhece alguma ferramenta de build.

Um bom jeito de começar a entender o Gradle é olhando seus predecessores como Ant e Maven. No Ant existe uma enorme liberdade para fazer as coisas que você quer e como quer. Por outro lado isso significa que nem mesmo uma estrutura padrão do projeto existe e cada projeto determina suas próprias regras, então a curva de entendimento de cada projeto e de cada empresa que você passasse era muito grande. Além disso o Ant não possui um gerenciador de dependências interno como as demais ferramentas de build, por outro lado ele se integra muito bem com o Ivy que faz este trabalho.

Foi então que chegou o Maven trazendo uma proposta de padronizar mais as coisas, definindo estruturas de projetos, já com um gerenciador de dependência internas, o conceito de plugins e uma série de outras regras. A contrapartida disto é que perdeu-se muito da flexibilidade em prol de uma padronização que determina onde as coisas devem ficar e como devem ser. Então qualquer programador que conhece o Maven vai conseguir se virar em qualquer projeto que utilize o mesmo.

O Gradle vindo depois destes então resolveu unir o que já existia de bom em uma nova ferramenta de build e ainda trazendo novas abordagens com a possibilidade de programar suas configurações através de uma linguagem simples baseada em Groovy e depois também em Kotlin, trazendo mais flexibilidade ainda, já que se pode criar funções e até fazer loops. É interessante ver como o Gradle conseguiu deixar a liberdade do Ant de você criar suas próprias tasks da forma que você quer mas dentro das padronizações vindas do Maven.

Fonte: https://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608

Estrutura do build.gradle

O arquivo principal do Gradle é o build.gradle, ele é equivalente ao pom.xml do Maven.

Exemplo de um build.gradle em um projeto com Quarkus

Quando olhava o build.gradle de projetos diferentes era aí que vinha a primeira impressão de bagunça, pois cada projeto define as mesmas coisas de diferentes formas e pensava que não havia padrão. Esse foi meu maior erro, não só tem um padrão como funciona de uma forma bem programática! Acontece que cada elemento do build.gradle possui uma ligação com uma classe Java, começando pelo próprio arquivo que é representado pela interface Project:

É possível ver esta interface e os demais métodos e atributos dela na documentação do Gradle: https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html

Descobrir isso para mim foi revelador, pois na verdade existe sim uma organização, existe um padrão, tudo o que você está declarando deve ser correspondente à estas classes do Gradle. Ainda não tive a oportunidade de analisar o código do Gradle mas entendo que quando você escreve um arquivo build.gradle você está praticamente escrevendo uma implementação destas interfaces com uma sintaxe amigável. De qualquer forma descobrir essa relação do arquivo com as classes Java do Gradle foi o que me fez passar a compreender o Gradle, foi algo como:

Outro bom exemplo é a escrita de uma task:

task myTask {
   doLast {
      3.times {
         println "Number $it"
      }
   }
}

E agora é mais fácil entender, temos a interface Task que possui entre os métodos o doLast(). Este é um método que é chamado ao final da execução de uma task. E a implementação do método é totalmente livre onde no caso fiz um loop para imprimir no console 3 vezes uma mensagem com o índice do loop.

Documentação da interface Task: https://docs.gradle.org/current/javadoc/org/gradle/api/Task.html

É possível ver elementos no build.gradle que não estão nestas interfaces apresentadas, nestes casos é muito provável que a classe correspondente destes elementos são de algum plugin que foi adicionado no projeto. Então basta verficar a documentação do plugin e verá as classes que procura.

Conclusão

Neste artigo foi possível ver que o Gradle trouxe uma proposta de ficar no meio termo entre o Maven e o Ant, isto é, ficando entre a padronização e a flexibilidade, também trazendo mais poder com a possibilidade de utilizar lógica de programação criando loops e até mesmo funções.

Além disso também vimos que o que todo elemento que adicionamos no script Gradle está relacionado a uma classe Java, o que nos faz ver que não é qualquer coisa que pode ser feita, deve haver essa relação para as coisas funcionarem.

Fontes

• Site do Gradle: https://gradle.org/
• Documentações do Gradle: https://docs.gradle.org/current/userguide/userguide.html
• Livro: Gradle in Action

Artigos

• Parte 1 — Introdução a série de artigos
• Parte 2 — Visão Geral
• Parte 3 — Novo Projeto e Wrapper