Gradle » History » Revision 5
« Previous |
Revision 5/9
(diff)
| Next »
Alexey Demakov, 11/10/2015 02:24 PM
Gradle-based build system.¶
История¶
Предыдущая версия системы сборки использовала Ant для управления сборкой и Ivy для управления зависимостями.
Система сборки представляла собой библиотечный Ant файл, который подключался к проекту и предоставлял
базовую функциональность по сборке Java проектов и управлению выпуском релизов.
Gradle реализует и расширяет эту функциональность, поэтому принято решение использовать этот инструмент для сборки проектов.
Ресурсы¶
Подключение Gradle к проекту¶
1. Установить gradle, определить переменную окружения GRADLE_HOME.¶
2. В каталоге проекта выполнить команду создания конфигурационных файлов для Java проекта:¶
> gradle init --type java-library
Другие доступные типы проектов: https://docs.gradle.org/current/userguide/build_init_plugin.html
Также будет создана обертка-запускач gradlew/gradlew.bat, которая избавляет от необходимости вручную
устанавливать gradle для сборки проекта - разработчику достаточно просто выкачать рабочую копию проекта из репозитория,
gradle будет установлен автоматически.
Имя проекта будет записано в settings.gradle. Gradle предполагает, что имя проекта совпадает с именем каталога проекта.
Если это не так, необходимо исправить имя проекта в файле settings.gradle.
Дополнительная информация:
https://docs.gradle.org/current/userguide/gradle_wrapper.html
https://docs.gradle.org/current/userguide/wrapper_plugin.html
3. Привести структуру папок в соответствие с соглашениями gradle:¶
src/main/java - код проекта
src/main/resources - ресурсы проекта
src/test/java - код тестов
Дополнительная информация:
https://docs.gradle.org/current/userguide/java_plugin.html#N12323
4. Указать зависимости проекта в build.gradle:¶
compile - зависимость, необходимая для сборки проекта
testCompile - зависимость, необходимая для сборки тестов
группа:имя:версия - формат зависимости
dependencies { // The production code uses the SLF4J logging API at compile time compile ''org.slf4j:slf4j-api:1.7.12'' // Declare the dependency for your favourite test framework you want to use in your tests. // TestNG is also supported by the Gradle Test task. Just change the // testCompile dependency to testCompile ''org.testng:testng:6.8.1'' and add // ''test.useTestNG()'' to your build script. testCompile ''junit:junit:4.12'' }
Дополнительная информация: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management
5. Указать репозитории, в которых ищутся зависимости¶
build.gradle:
repositories { // репозиторий ИСП РАН, подключается, если есть зависимости от наших проектов ivy { url = ''http://forge.ispras.ru/repo'' layout ''pattern'', { artifact ''[organization]/[ext]s/[artifact]-[revision](.[ext])'' } } // Use ''jcenter'' for resolving your dependencies. // You can declare any Maven/Ivy/file repository here. jcenter() }
Дополнительная информация: https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories
6. Настроить опции компиляции Java¶
build.gradle:
sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 compileJava { options.encoding = "UTF-8" }
Команда компилцяии Java файлов:
> gradlew compileJava
Компиляция и прогон тестов:
> gradlew test
Дополнительная информация: https://docs.gradle.org/current/userguide/java_plugin.html#N1245A
7. Подключить плагин для сборки дистрибутива¶
Для приложений (дистрибутив содержит библиотеки и скрипты для запуска):
build.gradle:
apply plugin: ''application'' ... mainClassName = "org.gradle.sample.Main"
Для библиотек (application plugin подключает это автоматически):
build.gradle:
apply plugin: ''distribution''
Команда сборки дистрибутива
> gradlew distZip
или
> gradlew distTar
оба сразу:
assembleDist
Дополнительная информация:
https://docs.gradle.org/current/userguide/distribution_plugin.html
https://docs.gradle.org/current/userguide/application_plugin.html
8. Подключить плагин для выпуска релизов¶
build.gradle:
// в начало файла import java.text.SimpleDateFormat import java.util.regex.Matcher import org.gradle.api.Project plugins { id ''net.researchgate.release'' version ''2.3.4'' } ... // в конец файла release { failOnCommitNeeded = false versionPatterns = [ // Increments build number: "0.2.5-alpha-150428" => "0.2.6-alpha-150428" /(^\d+\.\d+\.)(\d+)(-[^-]*)(-[^-]*$)/: { Matcher m, Project p -> m.replaceAll("${ m[0][1] }${ (m[0][2] as int) + 1 }${ m[0][3] }" ) } ] } task setReleaseData << { project.version=project.version+''-''+new SimpleDateFormat("yyMMdd").format(new Date()) } confirmReleaseVersion.dependsOn setReleaseData
Готовящаяся к выпуску версия (вместо текущей даты SNAPSHOT) хранится в файле gradle.properties:
version=0.1.28-alpha-SNAPSHOT
Команда выпуска новой версии:
> gradlew release
Будет предложено подтвердить или изменить номер выпускаемой версии, а затем номер следующей готовящейся версии.
Дополнительная информация: https://github.com/researchgate/gradle-release
Хорошо бы согласовать систему нумерации версий с семантическим версионированием.
Есть плагин, поддерживающий этот подход: https://plugins.gradle.org/plugin/de.gliderpilot.semantic-release
9¶
Компиляция, прогон тестов и запуск инструментов статического анализа кода:
> gradlew check
10. Копирование зависимостей в подкаталог ''libs''¶
gradle скачивает зависимости куда-то в свой кэш.
Это неудобно при использовании eclipse.
Мы привыкли, что библиотеки лежат рядом.
Копировать их в подкаталог ''libs'' проекта можно так:
build.gradle
//copying all dependencies attached to ''compile'' into a specific folder task copylibs(type: Copy) { //referring to the ''compile'' configuration from configurations.compile, configurations.testCompile into ''libs'' }
Запускать при изменении зависимостей:
> gradlew copylibs
В source code repository не класть!
Альтернатива - gradle eclipse plugin
Но .classpath генерируется не переносимый, в source code repository его не положишь.
Updated by Alexey Demakov about 9 years ago · 9 revisions