Introdução
O tópico desta revisão será o sistema de compilação automática Gradle. Em inglês, os sistemas de construção são chamados de
Build Tools .
![Uma rápida introdução ao Gradle - 1]()
Por que isso é necessário? Construir projetos manualmente em Java é um processo bastante trabalhoso. É necessário indicar corretamente as bibliotecas e frameworks que o projeto necessita e dos quais o projeto depende. Aqui você pode ler um excelente artigo sobre Habré: “
Trabalhando com Java na linha de comando ”. Mais cedo ou mais tarde você começará a criar alguns scripts para automatizar esse processo. Agora imagine que todos os desenvolvedores ao redor do mundo fazem isso e todos escrevem novamente o que alguém já escreveu para seu projeto. E então surgiram sistemas de montagem de projetos que automatizam esse processo. Além disso, por um lado, permitem montar um projeto da maneira que você deseja, por outro lado, fornecem ferramentas mais ou menos padronizadas. Uma alternativa ao Gradle é o sistema de construção automatizado Maven. Estes dois sistemas de montagem são, por um lado, diferentes, mas por outro lado, apresentam uma série de semelhanças. Há material sobre esse tema no site do Gradle: "
Migrando do Maven para o Gradle ". Conforme afirmado neste tutorial, Gradle e Maven têm uma perspectiva diferente sobre como construir um projeto. Gradle é baseado em um gráfico de tarefas, que podem depender umas das outras. As tarefas realizam algum tipo de trabalho. Maven usa um modelo de certas fases, às quais estão vinculados certos “objetivos”. Esses objetivos são onde algum trabalho é feito. No entanto, com estas diferentes abordagens, ambos os sistemas de construção seguem a mesma convenção e a gestão de dependências é semelhante. Para começar a usar o Gradle você precisa baixá-lo. No Google ou Yandex entramos em “Gradle Build Tool” e nos primeiros resultados vemos o site oficial:
https://gradle.org . Na página principal do Gradle há um link com o texto "Docs", que leva à
documentação do Gradle . Primeiro precisamos instalar (instalar) o Gradle, por isso estamos interessados na seção "
Instalando o Gradle " da documentação. Existem muitos métodos de instalação, incluindo o método “antiquado”, ou seja, manualmente (“
Instalando manualmente ”). De acordo com as instruções, baixe um arquivo do tipo “
somente binário ”, que terá um nome como gradle-5.1.1-bin.zip. A seguir, descompacte o arquivo e configure a variável de ambiente PATH de acordo com as instruções. O principal é que após executar as instruções, o comando
gradle -vmostra a versão do Gradle instalado. Pode haver um problema que, ao determinar a localização, o sistema não encontrará o Gradle onde você deseja. Portanto, no Windows você pode fazer (no *nix existem análogos):
for %i in (gradle.bat) do @echo. %~$PATH:i Agora, talvez, possamos começar a nos conhecer.
Inicializando um projeto Gradle
Gostaria de observar imediatamente que o Gradle trata da execução de tarefas chamadas
tarefas (vou chamá-las de tarefas). As tarefas são fornecidas por vários
plugins . Aconselho você a ler mais sobre plugins na documentação oficial: "
Usando Gradle Plugins ". Existe um conjunto de "Plugins principais" que estão sempre disponíveis quando o Gradle é instalado. Existem diferentes categorias desses plugins, mas estamos interessados na categoria “
Utilitário ”. Este conjunto inclui o plugin "
Build Init Plugin ", que fornece tarefas para inicializar um projeto Gradle. Estamos interessados em criar um projeto do tipo: "
java-application ". Vamos executar a tarefa Gradle:
gradle init --type java-application vamos responder algumas perguntas ao longo do caminho, por exemplo, que queremos usar o Groovy DSL (linguagem de descrição de tarefa padrão para Gradle) e a estrutura de teste JUnit (falaremos sobre isso em outra revisão). Após a criação receberemos o seguinte conjunto de arquivos:
Primeiramente, após a inicialização recebemos um wrapper especial pré-configurado para nossa versão do Gradle - este é um script especial. Aconselho você a ler mais sobre isso na documentação oficial - “
The Gradle Wrapper ”. Em segundo lugar, vemos o Gradle Build Script - o arquivo build.gradle. Este é o arquivo principal, que descreve quais bibliotecas e frameworks nosso projeto usa, quais plugins precisam ser conectados ao projeto e descreve diversas tarefas. Aconselho você a ler mais sobre esse arquivo na documentação oficial: "
Build Script Basics ".
Plug-ins e tarefas
Se olharmos agora o conteúdo do Build Script, veremos a seção de plugins:
plugins {
id 'java'
id 'application'
}
Esses são os mesmos plug-ins dos quais falamos anteriormente. E se existem plugins, então existem tarefas que agora estão disponíveis para nós. Podemos executar o comando gradle tasks e ver o que podemos fazer agora com o projeto:
Por exemplo, ao executar
gradle runlançaremos a classe principal da nossa aplicação java:
Como podemos ver, o mesmo está escrito abaixo:
2 actionable tasks: 1 executed, 1 up-to-date O que isso significa? Isso significa que um total de 2 tarefas foram concluídas: Além disso, 1 foi realmente concluída e uma não foi executada, porque... está atualizado, ou seja, o estado é atual e nada foi feito. Podemos executar o chamado "Dry Run":
gradle run -m Vamos executar este comando, veremos quais tarefas serão executadas para executar a tarefa de execução:
Como podemos ver, um total de 4 tarefas foram concluídas: antes de run ser executado, ele executou as classes de tarefas de dependência. A classe em si possui 2 dependências e portanto também executou compileJava e processResources. Quando executamos uma tarefa, podemos executá-la enquanto visualizamos um determinado nível de logs (o nível de log determina a importância das mensagens que queremos ver). Por exemplo, podemos fazer
gradle run -i. Isso também nos mostrará mensagens informativas como:
Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.
Para mais informações sobre login no Gradle, aconselho consultar a documentação oficial: "
Gradle Logging ". Como podemos observar, a tarefa das classes foi ignorada porque está
UP-TO-DATE , ou seja, o estado é atual, nada precisa ser feito, portanto não houve ações. Isso ocorre porque por padrão o Gradle possui "
verificações atualizadas " ou a chamada construção incremental. Você pode ler mais sobre esse mecanismo na documentação do Gradle: "
Verificações atualizadas (também conhecido como Build Incremental) ". Mas este mecanismo pode ser desabilitado executando uma tarefa especificando o sinalizador --rerun-tasks. Por exemplo,
gradle run --rerun-tasks. Então veremos:
2 tarefas acionáveis: 2 executadas Como você pode ver, o número de tarefas executadas leva em consideração apenas o primeiro nível do gráfico, ou seja, a própria tarefa executada e as tarefas das quais ela depende diretamente, ou seja , Aulas. As tarefas das quais as classes dependem não são contadas aqui (embora sejam executadas quando a tarefa das classes é executada). Você também deve ler sobre as tarefas:
Dependências
Uma das principais tarefas de qualquer sistema de construção é gerenciar dependências, ou seja, quais bibliotecas/frameworks nosso projeto precisa. O sistema de build deve garantir que eles estejam disponíveis no momento certo e montar o artefato final de nossa aplicação da maneira correta. Por padrão, após gradle init para aplicativo java, veremos o seguinte conteúdo no script de construção:
dependencies {
implementation 'com.google.guava:guava:26.0-jre'
testImplementation 'junit:junit:4.12'
}
Aqui fica imediatamente claro o que estamos conectando. Mas sem algum entendimento, não está claro o que são implementação e testImplementation? Aqui precisamos voltar novamente à documentação do Gradle, já que a documentação do Gradle é bem escrita. É chamado de "
Gerenciando configurações de dependência ". Conforme indicado na documentação, cada dependência é declarada com um determinado escopo – a área dentro da qual esta dependência estará disponível. Este escopo é designado por alguma configuração, cada uma delas com um nome exclusivo. Também é interessante que muitos plug-ins do Gradle adicionam configurações predefinidas. Para saber quais configurações temos podemos executar:
gradle --console plain dependencies Assim veremos uma lista de todas as configurações disponíveis e suas dependências. Podemos filtrar esta lista para ver apenas as configurações disponíveis:
gradle --console plain dependencies | find " - " Como sabemos o que usar? Você terá que ler um pouco aqui. Porque Usamos o plugin "Java", então vamos começar com sua documentação e a seção "
Gerenciamento de dependências ". Aqui vemos que costumava haver uma configuração (também conhecida como escopo) chamada “compilar” e significava “dependência necessária durante a compilação”. Mas então foi substituído (em inglês Superseded) pela implementação. Você pode ler mais sobre substituição na seção "
Separação de API e implementação ". Acontece que essa dependência estará no “classpath de compilação”. Mas às vezes queremos que nossa dependência seja incluída no artefato final. Para que? Por exemplo, teremos um jar executável, que deverá conter tudo o que for necessário. O que então devemos fazer? Em primeiro lugar, não existe tal suporte “pronto para uso” (ou seja, por padrão, sem quaisquer ações adicionais). Isso se explica pelo fato de que cada um deseja coletar o arquivo à sua maneira e o Gradle tenta ser minimalista. Também não podemos usar arquivos jar no classpath (sem manipulações adicionais no código), porque não funciona dessa maneira (consulte "
Oracle: Adicionando classes ao caminho de classe do arquivo JAR " para obter mais detalhes). Portanto, a maneira mais bonita é o seguinte código no script de construção:
jar {
manifest {
attributes 'Main-Class': 'jrgradle.App'
}
from configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
Nas configurações da tarefa jar especificamos o que será adicionado ao manifesto do arquivo jar (veja "
Oracle: Configurando o Ponto de Entrada de uma Aplicação "). E então dizemos que todas as dependências necessárias para a compilação serão incluídas no jar. Uma alternativa é usar o "
Gradle Shadow Plugin ". Pode parecer complicado, mas outros plugins podem facilitar a vida. Por exemplo, ao criar uma aplicação web (em oposição a uma aplicação Java normal), usaremos um plugin especial - “
Gradle War Plugin ”, que tem um comportamento diferente e nossa vida será mais fácil lá (todas as dependências necessárias serão ser colocado em um diretório especial separado pelo próprio plugin. Esse trabalho é regulado pela forma como os aplicativos da web devem ser projetados. Mas isso é uma história completamente diferente).
Resultados
Gradle é uma excelente escolha para sistemas de construção de projetos. Isso é confirmado pelo fato de ser usado por desenvolvedores de projetos conhecidos como Spring e Hibernate. Apenas as coisas mais básicas foram discutidas acima. Atrás deles estão escondidos um milhão de recursos e oportunidades que os desenvolvedores têm. O Gradle também suporta a criação de projetos multimódulos, o que não é abordado nesta revisão, mas o próprio Gradle possui um excelente tutorial: “
Criando Builds Multiprojetos ”. Espero que esta revisão também tenha demonstrado que a documentação do Gradle foi escrita em 5+ e que você possa encontrar facilmente o que precisa se souber onde procurar. E isso acontecerá quando você entender o básico. Além disso, o Gradle possui ótimos tutoriais. Gostaria de finalizar com uma pequena lista do que mais você pode ver usando o Gradle:
#Viacheslav
GO TO FULL VERSION