Gradle: build.gradle vs. settings.gradle vs. gradle.properties

1. Visão geral

Neste artigo,we’ll look at the different configuration files of a Gradle Java project. Also, we’ll see the details of an actual build.

Você pode verificarthis article para uma introdução geral ao Gradle.

2. build.gradle

Vamos supor que estejamos apenas criando um novo projeto Java executandogradle init –type java-application. Isso nos deixará com um novo projeto com o seguinte diretório e estrutura de arquivos:

build.gradle
gradle
    wrapper
        gradle-wrapper.jar
        gradle-wrapper.properties
gradlew
gradlew.bat
settings.gradle
src
    main
        java
            App.java
    test
        java
            AppTest.java

Podemos considerar o arquivobuild.gradle como o coração ou o cérebro do projeto. O arquivo resultante para o nosso exemplo tem a seguinte aparência:

plugins {
    id 'java'
    id 'application'
}

mainClassName = 'App'

dependencies {
    compile 'com.google.guava:guava:23.0'

    testCompile 'junit:junit:4.12'
}

repositories {
    jcenter()
}

Consiste em código Groovy, ou mais precisamente, uma DSL (linguagem específica de domínio) baseada em Groovy para descrever as compilações. Podemos definir nossas dependências aqui e também adicionar coisas como repositórios Maven usados para resolução de dependências.

Os elementos fundamentais da Gradle são projetos e tarefas. Neste caso, como o pluginjava é aplicado, todas as tarefas necessárias para construir um projeto Java são definidas implicitamente. Algumas dessas tarefas sãoassemble,check,build,jar,javadoc,cleane muitos mais.

Essas tarefas também são configuradas de forma que descrevam um gráfico de dependência útil para um projeto Java, o que significa que geralmente é suficiente executar a tarefa de construção e o Gradle (e o plug-in Java) garantirá que todas as tarefas necessárias sejam realizadas .

Se precisarmos de tarefas especializadas adicionais, como, por exemplo, construir uma imagem Docker, ela também irá para o arquivobuild.gradle. A definição mais fácil possível de tarefas é assim:

task hello {
    doLast {
        println 'Hello example!'
    }
}

Podemos executar uma tarefa especificando-a como um argumento para a CLI Gradle da seguinte maneira:

$ gradle -q hello
Hello example!

Não fará nada útil, mas imprima "Olá, exemplo!" claro.

No caso de uma compilação de vários projetos, provavelmente teríamos vários arquivosbuild.gradle diferentes, um para cada projeto.

O arquivobuild.gradle é executado em uma instânciaProject, com uma instância do Projeto criada por subprojeto. As tarefas acima, que podem ser definidas no arquivobuild.gradle, residem na instânciaProject como parte de uma coleção de objetosTask. As próprias tarefas consistem em várias ações como uma lista ordenada.

Em nosso exemplo anterior, adicionamos um encerramento Groovy para imprimir "Olá, exemplo!" ao final desta lista, chamandodoLast(Closure action) em nosso objetohelloTask. Durante a execução deTask, o Gradle está executando cada um de seusActions em ordem, chamando o métodoAction.execute(T).

3. settings.gradle

O Gradle também gera um arquivosettings.gradle:

rootProject.name = 'gradle-example'

O arquivosettings.gradle também é um script Groovy.

Em contraste com o arquivobuild.gradle, apenas um arquivosettings.gradle é executado por compilação do Gradle. Podemos usá-lo para definir os projetos de uma compilação de vários projetos.

Além disso, também é possível registrar o código como parte de diferentes ganchos do ciclo de vida de uma construção.

A estrutura requer a existência desettings.gradle em uma compilação de vários projetos, embora seja opcional para uma compilação de projeto único.

Este arquivo é usado após a criação da instânciaSettings do build, executando o arquivo nele e, portanto, configurando-o. Isso significa que estamos definindo subprojetos em nosso arquivosettings.gradle assim:

include 'foo', 'bar'

e o Gradle está chamando o métodovoid include(String… projectPaths) na instânciaSettings ao criar a compilação.

4. gradle.properties

O Gradle não cria um arquivogradle.properties por padrão. Ele pode residir em locais diferentes, por exemplo, no diretório raiz do projeto, dentro deGRADLE_USER_HOME ou no local especificado pelo sinalizador de linha de comando-Dgradle.user.home.

Este arquivo consiste em pares de valores-chave. Podemos usá-lo para configurar o comportamento do próprio framework e é uma alternativa ao uso de sinalizadores de linha de comando para a configuração.

Exemplos de chaves possíveis são:

org.gradle.caching=(true,false)
org.gradle.daemon=(true,false)
org.gradle.parallel=(true,false)
org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)

Além disso, você pode usar este arquivo para adicionar propriedades diretamente ao objetoProject, por exemplo, a propriedade com seu namespace:org.gradle.project.property_to_set

Outro caso de uso é especificar parâmetros da JVM como este:

org.gradle.jvmargs=-Xmx2g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Observe que é necessário iniciar um processo JVM para analisar o arquivogradle.properties. Isso significa que esses parâmetros da JVM afetam apenas os processos da JVM ativados separadamente.

5. A construção em poucas palavras

Podemos resumir o ciclo de vida geral de uma compilação do Gradle da seguinte maneira, supondo que não o executemos como um daemon:

É lançado como um novo processo da JVM
Ele analisa o arquivogradle.properties e configura o Gradle de acordo
Em seguida, ele cria uma instânciaSettings para o build
Em seguida, ele avalia o arquivosettings.gradle contra o objetoSettings
Ele cria uma hierarquia deProjects, com base no objetoSettings configurado
Finalmente, ele executa cada arquivobuild.gradle em seu projeto

6. Conclusão

Vimos como diferentes arquivos de configuração do Gradle atendem a vários objetivos de desenvolvimento. Podemos usá-los para configurar uma compilação Gradle e também a própria Gradle, com base nas necessidades do nosso projeto.

TOC

Gradle: build.gradle vs. settings.gradle vs. gradle.properties