Глава 12. Среда сборки.

12.1. Настройка среды сборки с помощью gradle.properties.

Gradle предоставляет несколько опций, которые облегчают настройку процесса Java, исполняющего вашу сборку. Хотя их возможно настраивать в вашей локальной среде с помощью GRADLE_OPTS или JAVA_OPTS, определенные настройки такие, как настройки памяти JVM, домашняя папка Java, включение/выключение демона может быть более полезным хранить в системе контроля версия вместе с вашим проектом, чтобы вся команда работала в согласующейся среде. Настройка согласующейся среды для вашей сборки - просто расположение настроек в файле gradle.properties. Эта конфигурация применяется в следующем порядке (если опция настроена в нескольких местах, берется из последнего):

  • Из файла gradle.properties в папке сборки проекта.
  • Из файла gradle.properties в домашней папке пользователя gradle.
  • Из системных свойств, например, когда -D<какое-либо свойство> установлено в командной строке.

Когда настраиваете свойства, помните, что для запуска Gradle требуется Java JDK или JRE версии 7 или выше.

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

org.gradle.daemon
	  

Когда это свойство установлено в true, для запуска сборки используется демон Gradle. Для локальных разработчиков выставление этого свойства в true является предпочтительным. Среда разработчика оптимизирована для скорости и получения обратной связи, так что мы почти всегда запускаем Gradle с демоном. Для Непрерывной Интеграции мы запускаем Gradle без демона, так как для нее требуется среда оптимизированная для совместности и надежности.

org.gradle.java.home
	  

Указывает домашнюю папку Java для процесса сборки Gradle. В качестве этого свойства можно установить местоположение jdk или jre, однако, в зависимости от того, что делает ваша сборка, jdk безопаснее. Приемлемое свойство используется по умолчанию, если настройка не указан.

org.gradle.jvmargs
	  

Указывать jvmargs используемые для процесса демона. В особенности эта настройка полезна для модифицирования настроек памяти. На данный момент, настройки по умолчанию излишне щедрые по отношению к памяти.

org.gradle.configureondemand
	  

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

org.gradle.parallel
	  

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

org.gradle.workers.max
	  

Когда включена, Gradle использует максимальное количество worker'ов. Смотрите опцию --max-workers, чтобы узнать детали.

org.gradle.debug
	  

Когда установлена в true, Gradle будет запускать сборку в включенным удаленной отладкой, прослушивая порт 5005. Обратите внимание, что это эквивалентно добавлению -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 к командной строке JVM и заморозит виртуальную машину, пока отладчик подключен.

org.gradle.daemon.performance.enable-monitoring
	  

Когда установлена в false, Gradle не будет отслеживать использвание памяти запущенными демонами. Смотрите Секцию 6.5.5 Что может пойти не так при использовании демона?

12.1.1. Параллельные Java процессы.

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

Запуск дополнительной JVM для каждой сборки чрезвычайно затратен, вот почему, если вы установили org.gradle.java.home или org.gradle.jvmargs, мы рекомендуем использовать демона Gradle. Для деталей смотрите Главу 6 Демон Gradle.

12.2. Свойства Gradle и системные свойства.

Gradle предлагает множество различных способов добавления свойств в вашу сборку. С помощью опции командой строки -D вы можете передать системное свойство JVM, которая запускает Gradle. У опции -D команды gradle такой же эффект, как и у соответствующей опции команды java.

Вы также можете добавить свойства к вашим объектам проектов с помощью файлов свойств. Вы можете разместить файл gradle.properties в домашнюю папку пользователя Gradle (она определена переменной окружения 'GRADLE_USER_HOME', которая по умолчанию не установлена USER_HOME/.gradle) или в папку вашего проекта. Для многопроектных сборок вы можете поместить файлы gradle.properties в любую папку подпроекта. Получить доступ к свойствам, установленным в файле gradle.properties, можно через объект проекта. Файл свойств в домашней папке пользователя приоритетнее файлов в папках проектов.

Вы также можете добавить свойства прямо в ваш объект проекта с помощью опции командной строки -P.

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

Если переменная окружения выглядит как ORG_GRADLE_PROJECT_свойство=какое-либо_значение, тогда Gradle устанавливает свойству на вашем объекте проекта указанное значение. Еще Gradle поддерживает такое же поведение для системных свойств, но с другим шаблоном именования, который выглядит как org.gradle.project.свойство.

Еще вы можете установить системные свойства в файле gradle.properties. Если имя свойства в таком файле начинается с 'systemProp.', например, 'systemProp.propName', тогда оно и его значение будут установлены как системной свойство, без префикса. В многопроектной сборке, такие свойства устанавливаются только для корневого проекта, во всех остальных они будут проигнорированы. То есть, только файл gradle.properties корневого проекта будет проверен на наличие свойств с префиксом 'systemProp.'.

Пример 12.1. Установка свойств в файле gradle.properties

gradle.properties

gradlePropertiesProp=gradlePropertiesValue
sysProp=shouldBeOverWrittenBySysProp
envProjectProp=shouldBeOverWrittenByEnvProp
systemProp.system=systemValue
	  

build.gradle

task printProps {
    doLast {
        println commandLineProjectProp
        println gradlePropertiesProp
        println systemProjectProp
        println envProjectProp
        println System.properties['system']
    }
}
	  

Вывод команды gradle -q -PcommandLineProjectProp=commandLineProjectPropValue -Dorg.gradle.project.systemProjectProp=systemPropertyValue printProps

> gradle -q -PcommandLineProjectProp=commandLineProjectPropValue -Dorg.gradle.project.systemProjectProp=systemPropertyValue printProps
commandLineProjectPropValue
gradlePropertiesValue
systemPropertyValue
envPropertyValue
systemValue
	  

12.2.1. Проверка на наличие свойств проекта.

Вы можете получить доступ к свойству проекта в вашем скрипте сборки, просто используя его имя, как вы используете переменную. Если такого свойства не существует, то будет выброшено исключение и сборка завершится с ошибкой. Если ваш сборочный скрипт опирается на необязательный свойства, которые может установить пользователь, возможно в файле gradle.properties, ваш необходимо проверить их существование перед использованием. Мы можете это сделать с помощью метода hasProperty('имяСвойства'), который возвращает true или false.

12.3. Выход в интернет через прокси.

Настройка HTTP или HTTPS прокси (например, для загрузки зависимостей) выполняется через стандартные системные свойства JVM. Эти свойства могут быть установлены прямо в сборочном скрипте; например, установить хост HTTP прокси можно так - System.setProperty('http.proxyHost', 'www.somehost.org'). В качестве альтернативы, свойства могут быть определены в файле gradle.properties либо в корневой папке сборки, либо в домашней папке Gradle.

Пример 12.2. Настройка HTTP прокси

gradle.properties

systemProp.http.proxyHost=www.somehost.org
systemProp.http.proxyPort=8080
systemProp.http.proxyUser=userid
systemProp.http.proxyPassword=password
systemProp.http.nonProxyHosts=*.nonproxyrepos.com|localhost
	  

Для HTTPS есть отдельные настройки.

Пример 12.3. Настройка HTTPS прокси

gradle.properties

systemProp.https.proxyHost=www.somehost.org
systemProp.https.proxyPort=8080
systemProp.https.proxyUser=userid
systemProp.https.proxyPassword=password
systemProp.https.nonProxyHosts=*.nonproxyrepos.com|localhost
	  

Мы не может найти хороший обзор для всех возможных настроек прокси. Одно из мест поиска - константы в файле из проекта Ant. Ссылка на хранилище. Другое - страница Интернет Свойств из документации JDK.

12.3.1. Аутентификация NTLM.

Если ваша прокси требует NTLM аутентификацию, вы можете предоставить домен аутентификации вместе с именем пользователя и паролем. Есть два способа, которыми вы можете предоставить домен для аутентификации вашей NTLM прокси:

  • Установить в системное свойство http.proxyUser значение наподобие домен/имя_пользователя.
  • Предоставить домен аутентификации с помощью системного свойства http.auth.ntlm.domain.