Gradle: build.gradle или settings.gradle или gradle.properties

1. Обзор

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

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

2. построить.град

Предположим, что мы просто создаем новый Java-проект, запустив gradle init –type 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 ForEach!'
    }
}

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

$ gradle -q hello
Hello ForEach!

Ничего полезного в этом нет, но распечатайте «Hello ForEach!» конечно.

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

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

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

3. настройки.град

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=(правда,ложь)
• org.gradle.daemon=(правда,ложь)
• org.gradle.parallel = (правда, ложь)
• 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 .
• Он создает иерархию Projects на основе настроенного объекта Settings .
• Наконец, он выполняет каждый файл build.gradle для своего проекта .

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

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