TOC

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

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

1. обзор

В этой статьеwe’ll look at the different configuration files of a Gradle Java project. Also, we’ll see the details of an actual build.

Вы можете проверитьthis article для общего введения в Gradle.

2. build.gradleс

Предположим, что мы просто создаем новый проект 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 определяются неявно. Некоторые из этих задач:assemble,check,build,jar,javadoc,clean и многие другие.

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

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

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

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

$ gradle -q hello
Hello example!

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

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

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

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

3. settings.gradleс

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

rootProject.name = 'gradle-example'

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

В отличие от файлаbuild.gradle, только один файлsettings.gradle выполняется за одну сборку 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=(quiet,warn,lifecycle,info,debug)

Кроме того, вы можете использовать этот файл для добавления свойств непосредственно к объекту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, исходя из потребностей нашего проекта.

Related