Accelerate developer productivity
From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.
Build Anything
Write in Java, Kotlin, C++, or any language of your choice. Package for deployment on any platform. Go monorepo or multi-repo. And rely on Gradle’s unparalleled versatility to build it all.
Automate Everything
Use Gradle’s rich API and mature ecosystem of plugins and integrations to get ambitious about automation. Model, integrate and systematize the delivery of your software from end to end.
Deliver Faster
Scale out development with elegant, blazing-fast builds. From compile avoidance to advanced caching and beyond, we pursue performance relentlessly so your team can deliver continuously.
Gradle
Gradle — система автоматической сборки, построенная на принципах Apache Ant и Apache Maven. В Eclipse использовалась система Ant, но большинство разработчиков даже не замечало её работы. В основном возможности системы использовались в конторах для автоматизации различных задач. В Android Studio такой номер не пройдёт. Gradle сопровождает вас во время разработки постоянно. Поначалу, если вы перешли с Eclipse, Gradle сильно раздражает своими действиями. Но позже вы оцените её удобство и может даже полюбите её.
Gradle не является изобретением для Android Studio, система была разработана раньше и использовалась в приложениях для Java, Scala и других языках.
Система сборки Gradle очень мощная и сложная, чтобы о ней рассказать в двух словах. Есть целые книги о ней. Сами команды в Gradle представляют собой обычный текст с использованием синтаксиса Groove для конфигурации. Но нам не нужно знать всё. Познакомимся поближе с системой и научимся пользоваться ей.
Создайте новый проект или откройте любой существующий проект из Android Studio и посмотрите на структуру проекта.
В последних версиях студии файлы Gradle выделили в отдельную папку Gradle Script. Раскройте её. В основном вас должен интересовать файл build.gradle, который относится к модулю. Рядом с этим файлом в скобках будет написано Module: app. Двойным щелчком откройте его, вы увидите, что файл является текстовым.
Также есть файл build.gradle, который относится к проекту. Но с ним работают реже. Так находятся настройки для репозиториев и самого Gradle.
Вернёмся к файлу модуля, вы увидите много интересной информации. Например, вы там можете увидеть настройки, которые раньше вы могли видеть в манифесте — номера версий, номера SDK и так далее. Забегая вперёд, скажу, что здесь можно добавить всего одну волшебную строчку и нужная библиотека сама скачается из интернета и установится в проекте. Красота!
Однако вернёмся в корневую папку. Кроме файлов build.gradle мы можем заметить файлы gradle.properties, settings.gradle и другие. Трогать их не нужно.
В корневой папке также есть файлы gradlew и gradlew.bat для работы с Gradle Wrapper. В принципе вам не нужно знать о них ничего. Но для параноиков есть информация — если вы часто импортируете проекты из неизвестных источников, то они содержат файл gradle/wrapper/gradle-wrapper.properties. Откройте его текстовым редактором и посмотрите на адрес у distributionUrl. Путь должен вести на официальный сай //services.gradle.org или на внутренний корпоративный сервер. Другие адреса должны вызвать тревогу.
Вы могли заметить, что по сравнению с Eclipse изменилась структура файлов. В папке app находится папка src, а ней папка main, в которых папки java, res и файл манифеста. Новая структура лучше отвечает требованиям Gradle для управления файлами.
Вы, например, можете создавать альтернативные папки с ресурсами и с помощью build.gradle подключить их к проекту.
android < compileSdkVersion 20 buildToolsVersion "20.0.0" defaultConfig < applicationId "ru.alexanderklimov.hellokitty" minSdkVersion 16 targetSdkVersion 20 versionCode 1 versionName "1.0" >sourceSets < main < res < srcDirs = [ 'src/main/res', 'src/main/presentations/animations', 'src/main/presentations/layouts'] >> > >
В этом примере мы указали, что существуют новая папка presentations в папке /src/main/ наряду с существующими папками java и res. Внутри созданной папки есть ещё две папки layout и animations, которые содержат файлы ресурсов.
Только помните, что вам нужно избегать конфликта имён при слиянии всех файлов при сборке.
Значение sourceSets указывает Gradle, какие папки следует использовать. Этим приёмом пользуются продвинутые программисты. Мы пока не будем использовать такую технику.
Другая полезная возможность — создавать разные версии приложений, например, демо-версию и платную версию. Немного об этом рассказано здесь.
Номер версии приложения и требования к версии Android прописаны в секции defaultConfig. Если у вас сохранились старые версии приложений, то в манифесте можете удалить данные записи. По-моему, там даже выводится соответствующая подсказка. Даже если вы эти данные в манифесте не удалите, то значения из gradle.build имеют больший приоритет и перепишут значения в манифесте при не совпадении.
defaultConfig
Подключение библиотеки происходит одной строчкой. Например, нужно добавить библиотеку Picasso:
dependencies
В Android Studio 3.0 используется новая версия Gradle, в которой compile считается устаревшей. Вместо него следует использовать новое слово implementation.
implementation 'com.android.support:recyclerview-v7:27.0.0'
Есть похожая команда, которая подключает библиотеку, которая будет использоваться только для отладки приложения и в релизной версии она не нужна.
debugCompile 'junit:junit:4.12' // старый вариант testImplementation 'junit:junit:4.12' // новый вариант для Android Studio 3.0
Далее включаете синхронизацию и через несколько секунд в папке появляется нужная библиотека, готовая к использованию. Сама библиотека скачивается с специального хранилища-репозитория JCenter. Данный репозиторий используется по умолчанию и прописан в buil.gradle проекта.
repositories
Можно указать другой репозиторий, например, Maven Central.
repositories
Для поиска через Maven-репозиторий используйте The Central Repository Search Engine.
Библиотеку можно подключать и старым способом, используя jar-файл, но такой способ уходит в прошлое.
dependencies < compile files("libs/library1.jar", "libs/library2.jar") >
Сам файл нужно скопировать в папку /libs.
При любом изменении файла недостаточно его сохранить. Нужно также произвести синхронизацию. Наверху обычно появляется жёлтая полоска с ссылкой Sync Now.
Задаём имя APK при компиляции
Можно задать собственное имя при компиляции проекта. Например, так.
defaultConfig
Получим имя MyName-1.0.12-release.apk
Оптимизатор кода R8
Оптимизатор кода R8 имеет следующие возможности: урезание байт-кода, сжатие, обфускация, оптимизация, удаление «синтаксического сахара», преобразование в DEX. Оптимизатор может производить все операции за один шаг, что даёт сильное улучшение производительности. R8 был введён в Android Gradle plugin 3.3.0. Вам нужно только включить его.
android < buildTypes < release < minifyEnabled true > > >
R8 разработан для работы с существующими ProGuard-правилами, хотя возможны ситуации, когда нужно переработать правила.
#отключение R8 только для Android Library модулей android.enableR8.libraries = false #отключение R8 для всех модулей android.enableR8 = false
Сжимаем итоговый APK
В Gradle 1.4 появилась возможность сжать итоговый файл, убрав неиспользуемые ресурсы, в том числе из библиотек, например, Google Play Services.
buildTypes
Во время сборки приложения вы можете увидеть строку:
:android:shrinkDebugResources Removed unused resources: Binary resource data reduced from 2570KB to 1711KB: Removed 33% .
Другой способ убрать неиспользуемые ресурсы конфигурации. Например, вам не нужные локализованные ресурсы для всех языков, которые входят в библиотеку Google Play Services или Android Support Library и др. Оставим только нужные языки. Возможно, вы также не хотите поддерживать mdpi или tvdpi-разрешения в своём приложении. Мы можем установить языки и разрешения, которые используются в приложении, остальные будут исключены, что позволит уменьшить вес приложения.
// build.gradle android < defaultConfig < resConfigs "en", "ru" resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi", "xxxhdpi" >>
Можно перенести ключи из манифеста.
Чтобы их не светить, например, если выкладывать код на Гитхабе, то сделаем так.
defaultConfig
И в манифесте переделаем код.
В большинстве случаев это сработает, но иногда ключ требуется при компиляции и указанный пример может не сработать. В таком случае применяют другой вариант через manifestPlaceholders.
defaultConfig
В манифесте пишем.
Класс BuildConfig
В статье LogCat упоминался способ быстрого отключения журналирования.
Суть в следующем. Когда вы создаёте новые переменные в блоках defaultConfig или buildTypes (ветки debug и release), то Gradle создаёт специальный класс BuildConfig, и вы можете получить доступ к этим переменным.
Например, добавим переменную в defaultConfig
defaultConfig
На языке Java это равносильно String YOUR_TOKEN = «ABRAKADABRA»;
Теперь мы можем обратиться к созданной строке.
String token = BuildConfig.YOUR_TOKEN; // Что-то делаем со своей строкой
С секцией buildType ситуация интереснее. У секции есть два блока debug и release. Можно создать переменные с разными значениями, которые будут использоваться в зависимости от ситуации. Например, у вас есть собственное API для сервера. Для тестирования вы используете один адрес, а для финальной версии — другой адрес. Тогда вы просто указываете разные адреса в разных ветках. Переменные могут быть не только строковыми.
buildTypes < debug < buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/debug/"' buildConfigField "boolean", "REPORT_CRASHES", "true" >release < . тут какие-то другие записи buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/release/"' buildConfigField "boolean", "REPORT_CRASHES", "false" >>
Создаём код для перехода на веб-страницу.
Uri addressUri = Uri.parse(BuildConfig.API_URL); Intent openLinkIntent = new Intent(Intent.ACTION_VIEW, addressUri); startActivity(openLinkIntent);
Теперь вам не нужно переписывать каждый раз код. Загружаться будет страница по нужному адресу автоматически.
Разделяем отладочную и финальную версию
По такому же принципу можно организовать запуск новой версии программы, не затрагивая программу, которую вы установили с Google Play. Допустим вы на своём телефоне установили своё собственное приложение через Google Play. Теперь вам нужно написать новую версию и проверить на своём телефоне. Из-за конфликта имён новое тестируемое приложение перепишет финальную версию или вообще не установится. Поможет следующий трюк.
buildTypes < debug < applicationIdSuffix ".debug" versionNameSuffix "-debug" resValue "string", "app_name", "AboutCat (debug)" >release < minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' resValue "string", "app_name", "AboutCat" >>
В специальных переменных applicationIdSuffix и versionNameSuffix мы задаём суффиксы, чтобы избежать конфликта. А в переменной resValue указываем название программы для отладочной и финальных версий, чтобы на устройстве можно было их найти. Не забудьте при этом удалить строковый ресурс app_name в res/values/strings.xml, иначе получите ошибку при компиляции. Теперь можете спокойно запускать приложение с новым кодом, не боясь повредить своё любимое приложение.
Прячем секретную информацию
Следующий совет больше подходит для компаний. Когда подписывается приложение, то нужно указывать пароль, хранилище и т.д. Чтобы их не светить в студии, можно прописать их в переменных и поместить в секцию signingConfigs. Сервер сам найдёт нужные ключи и воспользуется ими в своих сценариях.
signingConfigs < release < storeFile "$" keyAlias "$" storePassword "$" keyPassword "$" > >
Автогенерация версии кода
Нашёл совет, сам не применял. Не обязательно вручную менять версию приложения в атрибутах versionCode и versionName, можно сделать через переменные, а они сами подставятся в нужное место. На любителя.
def versionMajor = 1 def versionMinor = 0 def versionPatch = 0 android < defaultConfig < versionCode versionMajor * 10000 + versionMinor * 100 + versionPatch versionName "$.$.$" > >
settings.gradle
Файл settings.gradle обычно состоит из одной строчки.
include ':app'
Это означает, что у вас используется один проект для работы. Если вы будете подключать другие проекты, то здесь появятся новые строки.
gradle.properties (Project Properties)
Несколько советов по настройке файла gradle.properties.
Режим параллельного выполнения
В этом файле можно найти закомментированную строку # org.gradle.parallel=true. Если модули вашего проекта не используют друг друга как зависимости, создавая перекрёстные ссылки, можно включать режим параллельного выполнения, что ускорит скорость сборки до ~30%.
org.gradle.parallel=true # включаем режим параллельного выполнения
Gradle-демон
Включение на компьютере демона Gradle даст значительный прирост в скорости сборки.
org.gradle.daemon=true # включаем демон
Режим конфигурации при необходимости
Если в проекте используется много модулей, то можно включить режим конфигурации при необходимости. Ускорение будет заметно при большом количестве используемых модулей:
org.gradle.configureondemand=true
Меняем номер версии библиотек в одном месте
Очень часто в проекте используются взаимосвязанные библиотеки с одинаковыми номерами.
dependencies < compile 'com.android.support:appcompat-v7:23.4.0' compile 'com.android.support:design:23.4.0' compile 'com.android.support:percent:23.4.0' compile 'com.android.support:cardview-v7:23.4.0' compile 'com.android.support:gridlayout-v7:23.4.0' //play services compile 'com.google.android.gms:play-services-location:9.2.1' compile 'com.google.android.gms:play-services-gcm:9.2.1' >
Можно быстро поменять у всех номера через переменную. Для этого используется секция ext, в которой указывается переменная и номер версии. Затем в секции dependencies номер версии заменяется на имя переменной
ext < supportLibraryVersion = '24.0.0'; playServicesVersion = '9.2.1' >dependencies < compile "com.android.support:appcompat-v7:$supportLibraryVersion" compile "com.android.support:design:$supportLibraryVersion" compile "com.android.support:percent:$supportLibraryVersion" compile "com.android.support:cardview-v7:$supportLibraryVersion" compile "com.android.support:gridlayout-v7:$supportLibraryVersion" //play services compile "com.google.android.gms:play-services-location:$playServicesVersion" compile "com.google.android.gms:play-services-gcm:$playServicesVersion" >
Обратите внимание, что одинарные кавычки заменяются на двойные, а символ $ указывает на строковый тип.
Расширенная версия с разными переменными в другом виде.
ext.compileSdkProjectVersion= 24 ext.buildToolsProjectVersion= '24.0.0' ext.supportLibraryVersion = '24.0.0' ext.googlePlayVersion = '8.4.0’ android < compileSdkVersion compileSdkProjectVersion buildToolsVersion buildToolsProjectVersion //… >dependencies
Если в проекте используются несколько модулей с одинаковыми зависимостями, то эти записи можно перенести в корневой build.gradle, чтобы не менять номера версий в каждом модуле.
Настройки в Android Studio
Рассмотрим настройки, доступные в Android Studio. Закройте текущий проект, чтобы увидеть стартовое окно студии. В правой части нажмите на пункт Configure. В следующем окне выберите пункт Settings, чтобы оказаться в окне настроек студии. В левой части найдите пункт Build, Execution, Deployment, затем подпункт Build Tools, далее подпункт Gradle. По умолчанию, там всё чисто, только указан путь у Service directory path. Это были общие настройки.
Теперь рассмотрим настройки, относящиеся к проекту. Запустите любой проект в Android Studio. Выберите меню File | Settings. . Снова пройдитесь по пунктам Build, Execution, Deployment | Build Tools | Gradle. Вы увидите практически такое же окно с небольшими изменениями. Теперь поле Linked Gradle Projects не будет пустым, а также появятся дополнительные настройки. По умолчанию рекомендуют использовать Use default gradle wrapper.
Gradle Task
На правой стороне Android Studio имеется вертикальная вкладка Gradle, которую можно развернуть. Она содержит список задач (task), которая выполняет Gradle при работе с текущим проектом. Вы можете выделить любую из этих задач и запустить её двойным щелчком. Можно выделить несколько задач.
Узнать debug.keystore: MD5 и SHA1
Иногда требуется узнать значения debug.keystore: MD5 и SHA1. Обычно их получают через командную строку. Но это долго и неудобно, так как нужно помнить все аргументы. Есть способ проще. Открываем вкладку Gradle, нажимаем на кнопку со стрелками Refresh all Gradle Projects. Затем последовательно открываем элементы Tasks | android и запускаем команду signingReport. В нижнем окне Run увидите нужную информацию.
Variant: debug Config: debug Store: C:\Users\klimo_000\.android\debug.keystore Alias: AndroidDebugKey MD5: BA:6F:23:49:2D:9A:9C:0C:44:75:E0:94:59:07:E0:22 SHA1: 9D:51:F4:B8:4B:15:57:4B:EC:79:67:DC:F4:7C:5B:FB:02:C6:A2:F7 Valid until: Thursday, 1 December 2044
Gradle Console
Когда выполняется какая-то задача Gradle, то ход её выполнения можно увидеть в окне Gradle Console. Открыть её можно через вкладку Gradle Console в нижней правой части студии.
Terminal
Запускать задачи Gradle можно и в окне Terminal.
На панели инструментов имеется значок Sync Project with Gradle Files, которую следует использовать при редактировании файлов Gradle. Как правило, студия также выводит предупреждающее сообщение с ссылкой при изменении файла, которая делает ту же работу.
Добавление зависимостей через интерфейс студии
В статье описывался способ включения библиотеки в проект через редактирование файла build.gradle. Существует альтернативный вариант через настройки студии. Щёлкните правой кнопкой мыши на имени модуля (app) и выберите пункт Open Module Settings (быстрая клавиша F4). В правой части окна находятся вкладки, которые оказывают влияние на файл build.gradle. Например, вкладка Dependencies содержит подключаемые библиотеки.
Чтобы добавить новую зависимость, нажмите на значок с плюсом и выберите нужный вариант, например, Library dependency. Откроется список доступных библиотек из репозитория Maven.
Конфигурация в Android Studio Flamingo
Иногда студия начинает дурить, ругается на несовместимость каких версий библиотек, компиляторов и прочее. Вот и в версии Flamingo проект перестал собираться после какого-то обновления.
Мои настройки, после которого студия собрала проект.
// Project plugins < id 'com.android.application' version '8.0.1' apply false id 'com.android.library' version '8.0.1' apply false id 'org.jetbrains.kotlin.android' version '1.8.0' apply false >// Module compileOptions < sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 >kotlinOptions
Дополнительное чтение
В примере работы с PDF-файлами в папке assets использована операция запрета на сжатие файлов, которое происходит по умолчанию.
Задачи Gradle — теория для общего развития.
Сборка Java-проекта с использованием Gradle
Этот урок освещает создание вами простого Java-приложения с использованием Gradle.
Что вы создадите
Вы создадите простое приложение и соберете его с помощью Gradle.
Что вам потребуется
- Примерно 15 минут свободного времени
- Любимый текстовый редактор или IDE
- JDK 6 и выше
Как проходить этот урок
Как и большинство уроков по Spring, вы можете начать с нуля и выполнять каждый шаг, либо пропустить базовые шаги, которые вам уже знакомы. В любом случае, вы в конечном итоге получите рабочий код.
Чтобы начать с нуля, перейдите в Настройка проекта.
- Загрузите и распакуйте архив с кодом этого урока, либо кнонируйте из репозитория с помощью Git: git clone https://github.com/spring-guides/gs-gradle.git
- Перейдите в каталог gs-gradle/initial
- Забегая вперед, установите Gradle
Когда вы закончите, можете сравнить получившийся результат с образцом в gs-gradle/complete .
Настройка проекта
Для начала вам необходимо настроить Java-проект перед тем, как собрать его Gradle’ом. Т.к. урок посвящен Gradle, сделаем проект максимально простым, насколько это возможно.
Создание структуры каталогов
В выбранном вами каталоге проекта создайте следующую структуру каталогов; к примеру, командой mkdir -p src/main/java/hello для *nix систем:
└── src └── main └── java └── hello
Внутри src/main/java/hello директории вы можете создать любые Java-классы, какие вы хотите. Для простоты и согласованности с остальной частью урока, Spring рекомендует вам создать два класса: HelloWorld.java и Greeter.java .
package hello; public class HelloWorld < public static void main(String[] args) < Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>package hello; public class Greeter < public String sayHello() < return "Hello world!"; >>Установка Gradle
Теперь, когда у вас есть проект, который вы можете собрать с Gradle, вам нужно установит сам Gradle.
Gradle можно получить, скачав zip-файл с gradle.org/downloads. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем gradle-version-bin.zip. (Вы также можете выбрать gradle-version-all.zip, тем самым получите исходники, документацию и бинарные файлы.)
Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.
Чтобы протестировать правильность установки Gradle, запустите в командной строке:
gradleЕсли всё было сделано правильно, то вы увидите сообщение:
:help Welcome to Gradle 1.8. To run a build, run gradle . To see a list of available tasks, run gradle tasks To see a list of command-line options, run gradle --help BUILD SUCCESSFUL Total time: 2.675 secs
Теперь у вас есть установленный Gradle.
Что может делать Gradle
Теперь, когда Gradle установлен, посмотрим, что он может делать. Прежде, чем вы создадите build.gradle для проекта, выможете проверить, какие доступны задачи:
gradle tasksВы должны увидеть список доступных задач. Если вы запустите Gradle в каталоге, в котором нет ещё файла build.gradle, то увидите несколько самых элементарных задач:
:tasks == All tasks runnable from root project == Build Setup tasks setupBuild - Initializes a new Gradle build. [incubating] wrapper - Generates Gradle wrapper files. [incubating] == Help tasks dependencies - Displays all dependencies declared in root project 'gs-gradle'. dependencyInsight - Displays the insight into a specific dependency in root project 'gs-gradle'. help - Displays a help message projects - Displays the sub-projects of root project 'gs-gradle'. properties - Displays the properties of root project 'gs-gradle'. tasks - Displays the tasks runnable from root project 'gs-gradle'. To see all tasks and more detail, run with --all. BUILD SUCCESSFUL Total time: 3.077 secs
Не смотря на то, что эти задачи доступны, они не представляют большого значения без конфигурации для сборки проекта. С build.gradle файлом, некоторые задачи будут более полезны. Список задач будет увеличиваться при добавлении плагинов в build.gradle , таким образом вы будете время от времени запускать tasks, чтобы проверить, какие задачи доступны.
Говоря о добавлении плагинов, в следующей части урока вы добавите плагин, который отвечает за базовую функциональность сборки Java-проектов.
Сборка Java кода
Начнем с простого, создадим очень простой build.gradle в корневой папке проекта(там, где src), который содержит только одну строчку:
apply plugin: 'java'Эта единственная строчка в конфигурации сборки приносит значительную пользу. Запустите gradle tasks снова и вы увидите новые задачи в списке, включая задачи для сборки проекта, создания JavaDoc и запуска тестов.
Вы будете изпользовать задачу gradle build достаточно часто. Эта задача компилирует, тестирует и упаковывает код в JAR-файл. Вы можете запустить её таким образом:
gradle buildЧерез несколько секунд, «BUILD SUCCESSFUL» будет означать, что сборка прошла успешно.
- classes. Скомпилированные .class файлы
- reports. Отчеты в течении сборки(такие как отчеты о тестировании)
- libs. Библиотеки для сборки проекта(обычно в виде JAR и/или WAR файлов)
Классы в каталоге с .class файлами генерируются во время сборки Java-кода. Соответственно, вы должны найти там HelloWorld.class и Greeter.class.
На данный момент проект не имеет зависимостей от библиотек, поэтому ничего нет в папке dependency_cache.
Каталог отчетов должен содержать отчет о выполнении тестов для проекта. Т.к. проект пока не содержит тестов, данный отчет будет нам неинтересен.
Каталог библиотек должен содержать JAR-файл с названием каталога проекта. В дальнейшем, вы увидите, как указывать имя JAR-файла и его версию.
Объявление зависимостей
Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.
К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.
Во первых, изменим HelloWorld.java , как показано ниже:
package hello; import org.joda.time.LocalTime; public class HelloWorld < public static void main(String[] args) < LocalTime currentTime = new LocalTime(); System.out.println("The current local time is: " + currentTime); Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.
Если бы вы запустили gradle build для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке.
Во-вторых, вам необходимо добавить источники сторонних библиотек:
repositories
Блок repositories означает, что сборка должна разрешать зависимости из Maven Central репозитория. Gradle опирается в основном на многие соглашения и возможности, определенные в инструменте сборки Maven, включая использование Maven Central как источник библиотек зависимостей.
Теперь, когда мы готовы к приему сторонних библиотек, объявим их:
dependencies
В блоке dependencies вы описываете единственную зависимость Joda Time. В частности, вы запрашиваете(читаем справа на лево) версию 2.2 библиотеки joda-time в joda-time группе.
Другое, что хотелось бы отметить, это необходимость указания ключевого слова compile , обозначающее доступность библиотеки во время компиляции(а если бы вы собирали WAR файл, то была бы включена /WEB-INF/libs папка в WAR). Также существуют другие заметные ключевые слова, среди которых:
- providedCompile . Требуемые зависимости для компиляции кода, но которые будут доступны во время работы кода контейнера(например, Java Servlet API)
- testCompile . Зависимости, используемые для компиляции и запуска тестов, но не требуемые для компиляции и запуска кода проекта
И наконец, назначим имя для нашего JAR артефакта.
jar блок определяет, как JAR файл будет назван. В данном случае мы получим gs-gradle-0.1.0.jar .
Теперь, если мы запустим gradle build , Gradle должен будет загрузить Joda Time зависимость из репозитория Maven Central и успешно собрать проект.
Сборка проекта с Gradle Wrapper
Gradle Wrapper является предпочтительным способом для начала Gradle сборки. Он содержит bat-скрипты для Windows и shell-скрипты для OS X и Linux. Эти скрипты позволяют вам запускать сборку с Gradle без необходимости установки самого Gradle в вашу систему. Чтобы это стало возможным, добавьте следующий блок в конец вашего build.gradle :
task wrapper(type: Wrapper)
Запустите следующую команду для загрузки и инициализации wrapper-скриптов:
gradle wrapperПосле того, как задачи отработают, вы заметите несколько новых файлов. Два скрипта в корневом каталоге, а jar-файл и properties-файл оболочки будут в папке gradle/wrapper .
└── initial └── gradlew └── gradlew.bat └── gradle └── wrapper └── gradle-wrapper.jar └── gradle-wrapper.properties
Gradle Wrapper теперь доступен вам для сборки проекта. Добавьте его в вашу систему контроля версий и каждый, кто клонирует ваш проект, сможет его собрать точно таким же способом. Gradle Wrapper можно использовать наравне с установленным Gradle. Pfgecnbnt wrapper-скрипт для выполнения задичи сборки точно так же, как вы делали ранее:
./gradlew buildРанее, когда вы запускали wrapper с конкретной версией Gradle, он загружал и кешировал бинарники Gradle для соответствующей версии. Gradle Wrapper спроектирован таким образом, чтобы было возможно сохранить его в репозитории вашей VCS и любой, кто его клонирует, сможет собрать ваш проект без необходимости устанавливать и настраивать Gradle определенной версии.
На данном этапе у вас есть собранный ваш код. В результате вы увидете:
build ├── classes │ └── main │ └── hello │ ├── Greeter.class │ └── HelloWorld.class ├── dependency-cache ├── libs │ └── gs-gradle-0.1.0.jar └── tmp └── jar └── MANIFEST.MF
В сборке содержатся два класса Greeter и HelloWorld , как и ожидалось, а также JAR-файл. Окиньте беглым взглядом:
$ jar tvf build/libs/gs-gradle-0.1.0.jar 0 Fri May 30 16:02:32 CDT 2014 META-INF/ 25 Fri May 30 16:02:32 CDT 2014 META-INF/MANIFEST.MF 0 Fri May 30 16:02:32 CDT 2014 hello/ 369 Fri May 30 16:02:32 CDT 2014 hello/Greeter.class 988 Fri May 30 16:02:32 CDT 2014 hello/HelloWorld.classЭто содержимое пакета файлов классов. Важно отметить, что даже, если вы и объявили joda-time как зависимость, библиотека не включена в пакет. И JAR-файл будет неспособен к выполнению.
Чтобы сделать этот код выполняемым, мы можем использовать плагин application . Добавьте его в ваш build.gradle файл.
apply plugin: 'application' mainClassName = 'hello.HelloWorld'Затем просто запустите ваше приложение!
$ ./gradlew run :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :run The current local time is: 16:16:20.544 Hello world! BUILD SUCCESSFUL Total time: 3.798 secs
Остановимся подробнее на упаковке зависимостей. К примеру, если бы мы собирали WAR-файл, общепризнанный формат, ассоциирующийся с упаковкой сторонних зависимостей, мы бы могли использовать WAR плагин. Если вы используете Spring Boot и хотите получить исполняемый JAR-файл, тогда вам пригодится spring-boot-gradle-plugin. На данном этапе, gradle недостаточно знает о выбранной вами системе. Но этого достаточно, чтобы приступить к работе с gradle.
В конечном счете, у вас должен получиться такой build.gradle файл:
apply plugin: 'java' apply plugin: 'eclipse' apply plugin: 'application' mainClassName = 'hello.HelloWorld' // tag::repositories[] repositories < mavenLocal() mavenCentral() >// end::repositories[] // tag::jar[] jar < baseName = 'gs-gradle' version = '0.1.0' >// end::jar[] // tag::dependencies[] dependencies < compile "joda-time:joda-time:2.2" >// end::dependencies[] // tag::wrapper[] task wrapper(type: Wrapper) < gradleVersion = '1.11' >// end::wrapper[]Здесь присутствует много закомментированных открывающихся и закрывающихся вставок. Они позволяют разделить на части файл сборки для наглядного объяснения данного урока. Их необязательно использовать в вашем рабочем файле сборки.
Итог
Поздравляем! Вы создали простой, но эффективный файл сборки Gradle для сборки Java проектов.
С оригинальным текстом урока вы можете ознакомиться на spring.io.
Инициализация Gradle-проекта — Java: Настройка окружения
Ручная компиляции кода довольно утомительный процесс даже во время обучения. В реальных приложениях такой подход просто не применим, слишком много действий придется делать руками. Для компиляции используются специальные системы сборки, такие как Maven или Gradle. Последний стал стандартом де-факто для новых приложений, поэтому рассмотрим работу именно с ним. Принцип у всех таких систем один и тот же, поэтому зная один, несложно разобраться и в других.
Gradle — это не просто автоматизатор компиляции. Это навороченная система сборки, где компиляция это всего лишь один из этапов. Сборка проекта – довольно широкое понятие. Она включает в себя компиляцию исходного кода, упаковку в jar, запуск тестов и другие шаги, необходимые для создания рабочего приложения. Ключевые возможности Gradle:
- Автоматическая сборка проекта. Gradle сам знает какие файлы и как надо собирать. Сам компилирует, сам упаковывает в JAR
- Быстрая инкрементальная сборка. Компилируется только то, что изменилось
- Управление зависимостями. Gradle сам качает и подключает библиотеки. И заодно умеет их обновлять
Полный список возможностей огромен . Большая часть из них работает автоматически, об этом не придется думать.
В повседневной работе Java-программист пользуется Gradle через редактор, но во время обучения нужно потратить немного времени на то, чтобы разобраться с тем как он работает. Иначе потом будет сложно, когда что-то пойдет не так и возникнет ошибка. Поэтому здесь мы проделаем все операции через консоль, а дальше подключим редактор.
Начнем с установки. Если Gradle у вас не установлен, то посмотрите инструкцию . Проверить установку можно так:
-v ------------------------------------------------------------ Gradle 8.4 ------------------------------------------------------------ Теперь инициализируем новый Gradle-проект:
# Создаем директорию для проекта mkdir hexlet-gradle-project cd hexlet-gradle-project # Запускаем инициализацию gradle init Дальше Gradle задаст несколько вопросов, на базе которых сформируется правильная структура. Если во время создания вы ошиблись и выбрали не тот вариант, то ничего страшного. Просто дойдите до конца и пересоздайте директорию с проектом. Потом запустите все заново. Разбираем вопросы:
type of project to generate: 1: basic 2: application 3: library 4: Gradle plugin Enter selection (default: basic) [1..4] Выбираем тип basic, который Gradle предлагает по умолчанию. Этот тип представляет собой базовую структуру проекта Gradle, которую дальше можно настроить и дополнить по мере необходимости
(default: Kotlin) [1..2] Выбираем язык для описания Gradle файлов. Kotlin DSL является выбором по умолчанию. Мы тоже будем использовать Kotlin
(default: hexlet-gradle-project): Просто жмем Enter. Текущее имя директории и есть имя проекта.
(some features may change in the next minor release)? (default: no) [yes, no] Выбираем yes. После этого появляется радостная надпись:
in 8m 46s Посмотрим на получившуюся структуру:
-a . . ├── .gitattributes ├── .gitignore ├── build.gradle.kts ├── gradle │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradle.properties ├── gradlew ├── gradlew.bat └── settings.gradle.kts 2 directories, 9 files Много всего, начнем по порядку.
Gradle сразу подготавливает проект к использованию через git добавив два файла .gitignore и .gitattributes. Игнорируются файлы сборки, которые попадут в директорию build и .gradle, это служебные файлы Gradle, которые он сам себе сгенерирует во время работы.
Файлы gradlew и gradlew.bat нужны для установки самого Gradle. Концепция здесь такая, Gradle во время создания проекта делает так, чтобы проект не использовал глобально установленный Gradle. Он скачивает сам себя в директорию gradle. Все команды будут запускаться через ./gradlew (в Windows ./gradlew.bat). Зачем так сделано? Так Gradle фиксирует версию. Если поменяется глобально установленная версия, то проект продолжит работать с той, с которой он работал. Меньше шансов что-то сломать, но сложнее в обновлении.
Файл settings.gradle.kts содержит различные настройки, например, там задается имя проекта. Остальное добавляется по мере развития и требований со стороны кода.
Файл build.gradle.kts – это основной файл Gradle, в котором на языке Kotlin описано то, как будет работать система сборки. Пока этот файл пустой, чуть позже мы его наполним
Далее нужно создать место, в котором будет располагаться исходный код нашего проекта. Внутри директории проекта создайте следующую файловую структуру: src/main/java/io/hexlet/example. Назначение директорий здесь следующее. Директория src (source) – место, в котором лежит весь исходный код проекта. Директория main отвечает за код проекта и дополнительные ресурсы (например, картинки). Внутри находится java, то есть тут лежит Java-код. Но подразумевается, что бывает и по-другому. И вот только внутри java начинается структура, соответствующая пакету проекта.
В директории example создайте новый Java-класс с именем App.java и добавьте туда код:
// Имя пакета // Соответствует структуре директорий внутри директории java package io.hexlet.example; public class App public static void main(String[] args) System.out.println("Hello, world!"); > > Само приложение готово. Теперь перейдем к настройке системы сборки. Откройте файл build.gradle.kts. Именно с этим файлом придется работать больше всего, настраивая Gradle для подключения новых библиотек и их конфигурации. Добавьте туда следующий код:
plugins // Поддержка запуска из командной строки application > repositories // Подключаем автоматическая работа с репозиторием Maven Central mavenCentral() > // Для плагина application указываем главный класс приложения application // Входная точка mainClass.set("io.hexlet.example.App") > Теперь все готово. Попробуем запустить проект, а в следующем уроке поговорим о том, как конкретно работать с Gradle:
> Task :run Hello, world! # Вот он вывод нашей программы Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно
- 130 курсов, 2000+ часов теории
- 1000 практических заданий в браузере
- 360 000 студентов
Наши выпускники работают в компаниях: