4.3.1. Структура build.gradle

В данном разделе описывается структура и основные элементы скрипта build.gradle.

buildscript

В секции buildscript задается следующее:

  • Версия платформы, на которой основан данный проект.

  • Набор репозиториев, из которых будут загружаться зависимости проекта. Настройка доступа к репозиториям описана ниже.

  • Зависимости, используемые системой сборки, включая плагин CUBA для Gradle.

После секции buildscript объявляются несколько переменных, используемых далее в скрипте.

cuba

Логика сборки, специфичная для CUBA, сосредоточена в Gradle плагине cuba. Он подключается в корне скрипта и в секциях configure каждого модуля:

apply(plugin: 'cuba')

Параметры плагина cuba задаются в секции cuba:

cuba {
    artifact {
        group = 'com.company.sales'
        version = '0.1'
        isSnapshot = true
    }
    tomcat {
        dir = "$project.rootDir/build/tomcat"
    }
    ide {
        copyright = '...'
        classComment = '...'
        vcs = 'Git'
    }
}

Рассмотрим доступные параметры:

  • artifact - задает группу и версию собираемых артефактов проекта. Имена артефактов формируются на основе имен модулей, заданных в settings.gradle.

    • group - группа артефактов.

    • version - версия артефактов.

    • isSnapshot - если установлено в true, то в именах артефактов будет присутствовать суффикс SNAPSHOT.

      Версию артефактов можно переопределить в командной строке, например:

      gradle assemble -Pcuba.artifact.version=1.1.1
  • tomcat - задает параметры сервера Tomcat, который используется для быстрого развертывания.

    • dir - расположение каталога установки Tomcat.

    • port - порт сервера; по умолчанию 8080.

    • debugPort - порт для подключения Java отладчика; по умолчанию 8787.

    • shutdownPort - порт для передачи команды SHUTDOWN; по умолчанию 8005.

    • ajpPort - порт AJP connector; по умолчанию 8009.

  • ide - задает некоторые параметры для Studio и IDE.

    • vcs - тип используемой в проекте VCS. В данный момент поддерживаются только Git и svn.

    • copyright - текст Copyright Notice, вставляемый в начало файлов исходных текстов.

    • classComment - текст комментария, который будет расположен над объявлением класса в исходных текстах Java.

  • uploadRepository - задает параметры репозитория, в который будут выгружаться собранные артефакты проекта при выполнении задачи uploadArchives.

    • url - URL репозитория. По умолчанию используется репозиторий Haulmont.

    • user - имя пользователя репозитория.

    • password - пароль пользователя репозитория.

      Параметры репозитория выгрузки артефактов можно передать в командной строке с помощью следующих аргументов:

      gradlew uploadArchives -PuploadUrl=http://myrepo.com/content/repositories/snapshots -PuploadUser=me -PuploadPassword=mypassword
dependencies

Данная секция описывает набор компонентов приложения, используемых в проекте. Компоненты указываются координатами артефакта их модуля global. В примере ниже используются три компонента: com.haulmont.cuba (компонент cuba платформы), com.haulmont.reports (премиум-дополнение reports) и com.company.base (кастомный компонент):

dependencies {
  appComponent("com.haulmont.cuba:cuba-global:$cubaVersion")
  appComponent("com.haulmont.reports:reports-global:$cubaVersion")
  appComponent("com.company.base:base-global:0.1-SNAPSHOT")
}
configure

Секции configure описывают конфигурацию модулей. Наиболее важная часть конфигурации - описание зависимостей, например:

configure(coreModule) {

    dependencies {
        // standard dependencies using variables defined in the script above
        compile(globalModule)
        provided(servletApi)
        jdbc(hsql)
        testRuntime(hsql)
        // add a custom repository-based dependency
        compile('com.company.foo:foo:1.0.0')
        // add a custom file-based dependency
        compile(files("${rootProject.projectDir}/lib/my-library-0.1.jar"))
        // add all JAR files in the directory to dependencies
        compile(fileTree(dir: 'libs', include: ['*.jar']))
    }

Есть возможность добавлять зависимости через конфигурацию server для модулей core, web и portal (модули, имеющие задачу с типом CubaDeployment). Это имеет смысл в некоторых случаях, например, когда для варианта развёртывания с помощью UberJar обращение к зависимости происходит до старта приложения, а сама зависимость нужна для всех вариантов развёртывания в конкретном модуле. Тогда объявление отдельно на уровне модуля (что нужно, например, для случая развертывания опции WAR) и через конфигурацию uberJar на уровне проекта вызовет ненужное дублирование зависимости для UberJar. Такие зависимости при выполнении задач deploy, buildWar и buildUberJar будут помещаться в серверные библиотеки.

Блок entitiesEnhancing позволяет описать конфигурацию bytecode enhancement (weaving) классов сущностей. Его нужно объявить как минимум в модуле global, однако можно включить его в конфигурацию каждого модуля по-отдельности.

Секции main и test здесь - это наборы исходников проекта и тестов, а необязательный параметр persistenceConfig позволяет явно указать набор файлов persistence.xml. Если не установлено, задача будет обрабатывать все персистентные сущности, перечисленные в файлах *persistence.xml, найденных в CLASSPATH.

configure(coreModule) {
    ...
    entitiesEnhancing {
        main {
            enabled = true
            persistenceConfig = 'custom-persistence.xml'
        }
        test {
            enabled = true
            persistenceConfig = 'test-persistence.xml'
        }
    }
}

Нестандартные зависимости модулей можно задавать в Studio в экране Project properties > Advanced. См. также контекстную помощь Studio.

В случае транзитивных зависимостей и конфликта версий будет использована стандартная стратегия разрешения версий Maven. Согласно этой стратегии, релизные версии имеют приоритет над snapshot-версиями, а более точный числовой квалификатор имеет приоритет над более общим. При прочих равных, строковые квалификаторы приоритизируются в алфавитном порядке. Пример:

1.0-beta1-SNAPSHOT         // низкий приоритет
1.0-beta1
1.0-beta2-SNAPSHOT         |
1.0-rc1-SNAPSHOT           |
1.0-rc1                    |
1.0-SNAPSHOT               |
1.0                        |
1.0-sp                     V
1.0-whatever
1.0.1                      // высокий приоритет

Иногда необходимо использовать определенную версию некоторой библиотеки, но другая версия той же библиотеки попадает в проект транзитивно из дерева зависимостей. Например, вы можете использовать версию 7.2-SNAPSHOT платформы CUBA при использовании компонента приложения, созданного для платформы версии 7.2.0. Согласно стратегии приоритетов, описанной выше, собранный проект будет использовать платформу версии 7.2.0, даже если вы укажете ext.cubaVersion = '7.2-SNAPSHOT' в файле build.gradle.

Чтобы использовать желаемую версию, настройте стратегию разрешения Gradle в своем файле build.gradle следующим образом:

allprojects {
    configurations {
        all {
            resolutionStrategy.eachDependency { details ->
                if (details.requested.group == 'com.haulmont.cuba') {
                    details.useVersion '7.2-SNAPSHOT'
                }
            }
        }
    }
}

В этом блоке кода мы добавили правило, согласно которому версия 7.2-SNAPSHOT будет использоваться для всех зависимостей группы com.haulmont.cuba.