«Gradle: build.gradle против settings.gradle против gradle.properties»

«1. Обзор

В этой статье мы рассмотрим различные файлы конфигурации Java-проекта Gradle. Кроме того, мы увидим детали фактической сборки.

Вы можете прочитать эту статью для общего введения в Gradle.

2. build.gradle

Предположим, что мы просто создаем новый Java-проект, запустив gradle init — тип java-application. Это оставит нас с новым проектом со следующей структурой каталогов и файлов:

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

Мы можем рассматривать файл build.gradle как сердце или мозг проекта. Результирующий файл для нашего примера выглядит так:

plugins {
    id 'java'
    id 'application'
}

mainClassName = 'App'

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

    testCompile 'junit:junit:4.12'
}

repositories {
    jcenter()
}

Он состоит из кода Groovy или, точнее, DSL (предметно-ориентированного языка) на основе Groovy для описания сборок. Здесь мы можем определить наши зависимости, а также добавить такие вещи, как репозитории Maven, используемые для разрешения зависимостей.

Основными строительными блоками Gradle являются проекты и задачи. В этом случае, поскольку применяется java-плагин, все необходимые задачи для сборки Java-проекта определяются неявно. Вот некоторые из этих задач: сборка, проверка, сборка, jar, javadoc, очистка и многие другие.

Эти задачи также настроены таким образом, что они описывают полезный граф зависимостей для Java-проекта, то есть обычно достаточно выполнить задачу сборки, и Gradle (и плагин Java) позаботится о том, чтобы все необходимое задачи выполняются.

Если нам потребуются дополнительные специализированные задачи, такие как, например, сборка образа Docker, они также будут помещены в файл build.gradle. Самое простое определение задач выглядит следующим образом:

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

Мы можем запустить задачу, указав ее в качестве аргумента CLI Gradle следующим образом:

$ gradle -q hello
Hello Baeldung!

Это не принесет никакой пользы, но распечатает «Привет, Баелдунг!» Конечно.

В случае многопроектной сборки у нас, вероятно, будет несколько разных файлов build.gradle, по одному для каждого проекта.

Файл build.gradle выполняется для экземпляра Project, при этом для каждого подпроекта создается один экземпляр Project. Приведенные выше задачи, которые можно определить в файле build.gradle, находятся внутри экземпляра проекта как часть набора объектов Task. Сами задачи состоят из нескольких действий в виде упорядоченного списка.

В нашем предыдущем примере мы добавили замыкание Groovy для вывода «Hello Baeldung!» в конец этого списка, вызвав действие doLast(Closure) для нашего объекта hello Task. Во время выполнения Task Gradle выполняет каждое из своих действий по порядку, вызывая метод Action.execute(T).

3. settings.gradle

Gradle также генерирует файл settings.gradle:

rootProject.name = 'gradle-example'

Файл settings.gradle также является сценарием Groovy.

В отличие от файла build.gradle, для каждой сборки Gradle выполняется только один файл settings.gradle. Мы можем использовать его для определения проектов многопроектной сборки.

Кроме того, мы также можем зарегистрировать код как часть различных хуков жизненного цикла сборки.

Фреймворк требует наличия settings.gradle в сборке с несколькими проектами, в то время как это необязательно для сборки с одним проектом.

Этот файл используется после создания экземпляра сборки Settings, путем выполнения файла для него и, таким образом, его настройки. Это означает, что мы определяем подпроекты в нашем файле settings.gradle следующим образом:

include 'foo', 'bar'

и Gradle вызывает метод void include(String… projectPaths) для экземпляра Settings при создании сборки.

4. gradle.properties

По умолчанию Gradle не создает файл gradle.properties. Он может находиться в разных местах, например в корневом каталоге проекта, внутри GRADLE_USER_HOME или в месте, указанном флагом командной строки -Dgradle.user.home.

Этот файл состоит из пар ключ-значение. Мы можем использовать его для настройки поведения самого фреймворка, и это альтернатива использованию флагов командной строки для настройки.

Примеры возможных ключей:

org.gradle.caching=(true,false) org.gradle.daemon=(true,false) org.gradle.parallel=(true,false) org.gradle.logging .level=(тихо,предупреждать,жизненный цикл,информация,отладка)

«Кроме того, вы можете использовать этот файл для добавления свойств непосредственно к объекту Project, например, свойства с его пространством имен: org.gradle.project.property_to_set

Другой пример использования — указание параметров JVM следующим образом:

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

Обратите внимание, что для анализа файла gradle.properties необходимо запустить процесс JVM. Это означает, что эти параметры JVM влияют только на отдельно запущенные процессы JVM.

5. Коротко о сборке

Общий жизненный цикл сборки Gradle можно обобщить следующим образом, предполагая, что мы не запускаем ее как демон:

Она запускается как новый процесс JVM. gradle.properties и соответствующим образом настраивает Gradle. Затем он создает экземпляр Settings для сборки. Затем он оценивает файл settings.gradle относительно объекта Settings. Создает иерархию проектов на основе настроенного объекта Settings. Наконец, он выполняет каждую сборку. .gradle относительно своего проекта

6. Заключение

Мы видели, как разные файлы конфигурации Gradle выполняют различные задачи разработки. Мы можем использовать их для настройки сборки Gradle, а также самого Gradle в зависимости от потребностей нашего проекта.