Java with 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

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 — теория для общего развития.

Введение в Gradle

Работая с Kotlin Multiplatform Mobile для iOS разработчика главным испытанием становится не изучение Kotlin, а изучение билд системы Gradle, которая собирает мультиплатформенную библиотеку. В данном разделе разобрано что есть Gradle с перспективы iOS разработчиков.

Gradle​

Gradle это система сборки, имеющая гибкую систему конфигурации через плагины и позволяющая описывать конфигурацию сборки в виде groovy / kotlin файлов.

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

Также Gradle имеет управление зависимостями (подключение внешних библиотек или разных модулей одного проекта). Зависимости скачиваются с Maven репозиториев, например mavenCentral (хоть сам Maven тоже является билдсистемой, но Gradle использует от него только репозитории, на которых хранятся скомпилированные опубликованные зависимости).

Gradle написан на java и является JVM (Java Virtual Machine) приложением, то есть для его использования требуется установленная на исполняемой машине JDK (Java Development Kit). Наиболее стабильная версия JDK — Oracle JDK (рекомендуется к скачиванию Oracle JDK 11 для работы с KMM).

Gradle имеет обширную, подробную документацию, доступную тут.

Gradle Daemon​

Это долгоживущий фоновый процесс, который запускается на выбранной JVM при первой сборке. Он помогает избежать затратного процесса начальной загрузки JVM, при этом кешируя данные о ваших предыдущих билдах в память, что заметно ускоряет скорость сборки проекта.

Подробнее о Gradle Daemon и как его подключать к проекту вы можете прочитать тут и тут.

Контекст для понимания дальнейших разделов​

1. Gradle при каждом запуске проходит по нескольким фазам — инициализация, конфигурация, выполнение.
2. Файлы gradle могут быть написаны как на groovy (тогда расширение просто .gradle , так и на Kotlin Script .gradle.kts ). При использовании Kotlin Script IDE предоставляет полноценный анализ с подсказками, поэтому мы используем только Kotlin Script вариант.

Составляющие конфигурации проекта​

Проект, использующий Gradle в качестве системы сборки, содержит:

1. settings.gradle / settings.gradle.kts — настройки проекта, например подключение модулей проекта;
2. build.gradle / build.gradle.kts — конфигурация конкретного gradle модуля;
3. gradle.properties — файл содержащий набор ключ+значение передаваемыми в gradle.

settings.gradle​

Файл с настройками всего проекта (данные настройки влияют на все модули).
Может быть написан на groovy (тогда имя settings.gradle ) либо на kotlin — settings.gradle.kts .
Подробная информация в документации .
Код в данном файле выполняется в момент инициализации проекта (при каждом запуске градл происходит по стадиям инициализация, конфигурация, выполнение).

Пример содержимого с пояснениями:

// блок pluginManagement позволяет настроить работу с плагинами билдсистемы pluginManagement  // определяем список maven репозиториев, в которых нужно искать подключаемые плагины.  // Если данный блок не объявлять то будет использоваться gradlePluginPortal - https://plugins.gradle.org/  repositories  mavenCentral()  google()  > > // данный блок позволяет настроить для всех модулей проекта работу с зависимостями dependencyResolutionManagement  // определяем список maven репозиториев, в которых нужно искать подключаемые библиотеки.  repositories  mavenCentral()  google()  > > // подключение composite build - является темой для продвинутого погружения, обычно на проектах это не встретить // если кратко - это подключение другого самостоятельного gradle проекта к сборке нашего проекта, с возможностью подключать модули подключенного проекта как внешние зависимости в нашем проекте // https://docs.gradle.org/current/userguide/composite_builds.html includeBuild("network-generator") // подключение модулей проекта, каждый из них будет определяться как gradle модуль и будет читаться его build.gradle файл // двоеточие в пути обозначает уровень иерархии в файловой структуре. include(":network") include(":sample:mpp-library") 

Является упрощенным вариантом с moko-network.

(!) Основной сценарий когда iOS разработчику нужно работать с файлом settings.gradle — разработчик сам создает новый gradle модуль и нужно подключить его к билдсистеме. То есть добавляет include(«:mymodule») .

build.gradle​

Файл с конфигурацией модуля gradle проекта. Определяет всю логику сборки данного модуля (что собираем, как собираем).
Может быть написан на groovy (тогда имя build.gradle ) либо на kotlin — build.gradle.kts .
Подробная информация в документации.

Пример содержимого с пояснениями:

// подключение плагинов, которые и содержат всю основую логику сборки plugins  // плагин для сборки android библиотек. Требуется у нас в проектах так как мы собираем из мультиплатформы android код, помимо ios  // подробнее - https://developer.android.com/studio/build/index.html  id("com.android.library")  // плагин мультиплатформы. дает возможность собирать kotlin код разными компиляторами - Kotlin/JVM, Kotlin/JS, Kotlin/Native.  // подробнее - https://kotlinlang.org/docs/mpp-dsl-reference.html  id("org.jetbrains.kotlin.multiplatform")  // наш плагин мобильной мультиплатформы, упрощает настройку градл проектов для mobile использования (android, ios)  // подробнее - https://github.com/icerockdev/mobile-multiplatform-gradle-plugin  id("dev.icerock.mobile.multiplatform")  // плагин для генерации кода сериализации в момент компиляции, от библиотеки kotlinx.serialization  // подробнее - https://github.com/Kotlin/kotlinx.serialization  id("org.jetbrains.kotlin.plugin.serialization") > // объявление зависимостей данного модуля. Чем меньше зависимостей объявлено, тем быстрее будет производиться компиляция модуля. // зависимости ищутся в репозиториях, которые могут быть указаны как в самом build.gradle, так и в settings.gradle централизованно dependencies  // подключение зависимости к common коду, в виде реализации (implementation). Это означает что классы данной зависимости не будут видны вне данного модуля, без явного ее подключения.  commonMainImplementation(Deps.Libs.MultiPlatform.coroutines)  // подключение зависимости к common коду, транзитивно (api). Это означает что классы данной зависимости будут видны вне данного модуля при подключении нашего модуля.  commonMainApi(Deps.Libs.MultiPlatform.kotlinSerialization)  commonMainApi(Deps.Libs.MultiPlatform.ktorClient)  // подключение зависимости к андроид таргету, транзитивно. Классы данной зависимости видны только в androidMain сорссете.  androidMainApi(Deps.Libs.Android.ktorClientOkHttp)  // подключение зависимости к ios таргету, транзитивно. Классы данной зависимости видны только в iosMain сорссете.  iosMainApi(Deps.Libs.Ios.ktorClientIos)  // подключение другого модуля нашего проекта, в виде реализации  commonMainImplementation(project(":network"))  // подключение зависимостей к общему коду тестов, в виде реализации.  commonTestImplementation(Deps.Libs.MultiPlatform.ktorClientMock)  commonTestImplementation(Deps.Libs.MultiPlatform.Tests.kotlinTest)  commonTestImplementation(Deps.Libs.MultiPlatform.Tests.kotlinTestAnnotations)  // подключение зависимостей к андроид таргету тестов, в виде реализации.  androidTestImplementation(Deps.Libs.Android.Tests.kotlinTestJUnit) > 

Является упрощенным вариантом с moko-network.

Основные сценарий когда iOS разработчику нужно работать с файлом build.gradle :

1. Подключение новой зависимости к модулю
2. Подключение плагина с дополнительным функционалом ( например moko-resources / moko-network)

gradle.properties​

Файл с опциями выполнения gradle.
Подробнее в документации.

Пример содержимого с пояснениями:

# сколько максимум оперативной памяти gradle может использовать org.gradle.jvmargs=-Xmx4096m # выключение опции "конфигурация налету", так как многомодульные проекты с ней ломаются часто org.gradle.configureondemand=false # включение параллельной сборки - разные gradle модули могут выполнять свои задачи параллельно org.gradle.parallel=true # какой вариант кодстайла котлина используеся в проекте - используется IDE для включения верного кодстайла kotlin.code.style=official # специальные флаги для активации Commonizer чтобы в iosMain видно было методы ios, а не только в iosArm64 и iosX64 # подробнее тут - https://www.youtube.com/watch?v=Q99HvynwjtY # https://kotlinlang.org/docs/migrating-multiplatform-project-to-14.html#try-the-hierarchical-project-structure kotlin.native.enableDependencyPropagation=false kotlin.mpp.enableGranularSourceSetsMetadata=true kotlin.mpp.enableCompatibilityMetadataVariant=true # использование androidX библиотек для андроида, нужно android gradle plugin android.useAndroidX=true # отключение предупреждения о том что используется ios шорткат для настройки таргетов ios mobile.multiplatform.iosTargetWarning=false # путь до xcode проекта или воркспейса, используется Kotlin Multiplatform Mobile плагином для Android Studio чтобы запускать ios приложение с отладчиком # Подробнее https://plugins.jetbrains.com/plugin/14936-kotlin-multiplatform-mobile xcodeproj=./sample/ios-app 

Является упрощенным вариантом с moko-network.

Gradle Sync

Система сборки Gradle не связана напрямую с IDE и расчитана в первую очередь на работу без UI, через консоль. Но в IDEA и Android Studio реализована полная интеграция с Gradle, позволяющая запускать команды Gradle, видеть модули Gradle и прочее. Чтобы IDE могла считать конфигурацию проекта используется импорт проекта, называется действие Gradle Sync.

Кнопка для запуска Gradle Sync в Android Studio:

После успешного завершения импорта проекта, через Gradle Sync, мы получаем проиндексированный проект, в котором каждый gradle модуль обработан и считаны подключенные зависимости, настройки проекта (используется ли котлин, мультиплатформа и прочее):

Также после импорта проекта в IDE доступна панель работы с Gradle — в ней можно посмотреть все Gradle модули и все задачи, которые доступны в каждом модуле:

Самая полезная, и часто используемая для iOS разработчиков задача — скомпилировать iOS фреймворк и перенести в директорию для Cocoapods.

Зовется она syncMultiPlatformLibraryDebugFrameworkIosX64 (добавляется плагином mobile-multiplatform). Где:

• MultiPlatformLibrary — имя фреймворка, который будет получен на выходе
• Debug — конфигурация сборки (для разработки собираем дебаг с отладочной инфой, Release делает CI)
• IosX64 — таргет, который должен быть собран (то есть iOS для запуска в симуляторе на x64 машине)

Для разработки используем именно Debug + IosX64, так как этот вариант имеет оптимизацию на уровне Kotlin/Native компилятора с множеством кешей. Работает быстрее всех остальных вариантов сборки фреймворка.

Внесение изменений в конфигурацию

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

Например, плагин org.jetbrains.kotlin.multiplatform добавляет блок kotlin и множество задач типа compileKotlinIosX64 (если в блоке kotlin включен таргет iosX64 ).

Детальная информация о том какие настройки доступны в блоке kotlin доступна на сайте документации.

Помимо документации узнать досутпный функционал предоставляемый плагином можно используя подсказки IDEA, когда используется Gradle Kotlin DSL, вместо Groovy. В таком случае, при успешно завершенной индексации (после клика на Gradle Sync) можно использовать автозавершение кода и переход к объявлению.

Использование автодополнения (либо подождать при наборе кода, либо нажать ctrl + space )

Использование перехода к объявлению типа ( Cmd + left click ):

Gradle

Gradle — система для автоматизации сборки приложений и сбора статистики об использовании программных библиотек, применяющая языки Groovy, Java, JavaScript, Kotlin и т. д., а также решения из фреймворков Apache Ant и Apache Maven.

Освойте профессию «Java-разработчик»

Gradle написана на языках Java, Groovy и Kotlin, также поддерживает плагины на JavaScript, C++, Swift, Scala. Система распространяется как программное обеспечение с открытым исходным кодом по лицензии Apache License 2.0.

Назначение Gradle

Ручная сборка приложения для запуска на устройстве требует много времени и ресурсов. Она затягивает процесс разработки и релиза.

Чтобы ускорить его, программисты создают скрипты, автоматизирующие выполнение типовых задач. Это сокращает время сборки, но усложняет работу над командным проектом другим разработчикам.

Проблему решили системы автоматической сборки приложений. Первая — Ant — появилась в 2000 году. В 2004 году вышла Maven. Для описания сценариев сборки системы использовали язык разметки XML. Его недостаток — неконтролируемое разрастание при попытках собрать крупный многомодульный проект.

Профессия / 14 месяцев
Java-разработчик

Освойте востребованный язык

В 2006 году появилась первая версия Gradle. Она позволила решить основные проблемы:

• реализацию больших многомодульных сборок путем последовательного и параллельного выполнения основных и добавочных модулей;
• ускорение сборки за счет кеширования компонентов через общую сеть с использованием Gradle Build Cache;
• управление зависимостями, то есть подключаемыми к проекту фреймворками, библиотеками и другими компонентами;
• упрощение рабочего процесса за счет автоматизации типовых задач и веб-визуализации сборки.

Gradle использует многие решения, которые применяются в Ant и Maven. Три системы широко интегрированы друг с другом: проект, разработанный для одной из них, можно собрать в другой. Например, основным источником подключаемых внешних компонентов в Gradle является хранилище Maven.

Особенности Gradle

Использование диалекта Groove и Kotlin вместо XML

Оба объектно-ориентированных языка разработаны как дополнения к Java, используют похожий синтаксис, совместимы с теми же библиотеками и другим Java-кодом. Благодаря ему стало проще писать сценарии сборки и сравнительно быстро создавать сложные проекты.

Выполнение задач, основанное на направленных ациклических графах

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

Два примера описывают выполнение одной и той же задачи:

Код на Gradle проще и меньше. Разница заметна при реализации сборок с большим числом зависимостей.

Декларативный характер сборки

Разработчик просто задает цели, желаемый конечный результат, а система сама подбирает пути его достижения.

Структурирование сборки

Благодаря использованию общих принципов проектирования Gradle позволяет создать удобный, понятный и быстро реализуемый проект.

Проработанный API

Подробный и хорошо продуманный программный интерфейс упрощает отслеживание и настройку конфигурации сборки, контроль ее исполнения.

Универсальность

Система совместима с задачами Ant, инфраструктурой репозитория (сетевого хранилища) Maven и lvy, где можно опубликовать и получить зависимые компоненты. Есть также конвертеры для превращения Maven pom.xml в скрипт Gradle.

Станьте Java-разработчиком
и создавайте сложные сервисы
на востребованном языке

Простота миграции

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

Открытый код

Система распространяется по свободной лицензии Apache Software License (ASL), поэтому сторонние разработчики смогли написать множество полезных плагинов, библиотек и других компонентов. Они расширяют функционал и создают полноценную Gradle-экосистему.

Gradle Wrapper

Опция разрешает реализацию сборок, созданных в Gradle, на машинах, где система не установлена. Это упрощает непрерывную интеграцию серверов.

Гибкость языка

Groove, в отличие от жестко заданных XML-иерархий Ant и Maven, дает разработчику больше вариантов действия, позволяет оптимизировать проект.

Поддержка каскадной модели

Система сама определяет, какие компоненты дерева разработки были изменены или остались прежними. И, соответственно, какие зависящие от них задачи нужно перезапустить и обновить.

Как работает Gradle

В общем виде Gradle создает текстовый файл сценария сборки (BuildScript), состоящей из следующих компонентов:

• Project (проект). Это конечный результат работы сценария. Проект представляет собой JAR-файл, веб-приложение или zip-файл, включающий Java-архивы, созданные другими проектами. Проект может состоять как из одного модуля (одномодульный проект), так и из нескольких подмодулей (многомодульный проект). В многомодульном проекте каждый подмодуль можно рассматривать как самостоятельный Gradle-проект.
• Task (задачи). Это набор действий с проектом. Задачи могут быть связаны друг с другом. Под сборкой проекта понимается выполнение одной или нескольких связанных задач. Проект считается успешно собранным, когда выполняется задача или набор связанных задач. Как правило, результат сборки – набор артефактов, дистрибутивов, их размещение в репозитории, установка и запуск на другом компьютере в Сети.
• Dependency (зависимости). В ходе сборки могут быть использованы зависимости. Они бывают внешними и внутренними. Внешние — библиотеки, созданные разработчиками со всего мира и расположенные в репозиториях (repositories). Внутренние (подмодули в многомодульных проектах) — библиотеки, разработанные внутри текущего проекта и оформленные в виде подмодуля.

Описание проекта находится в файле build.gradle, настройки указываются в файле gradle.settings. Функциональность скрипта build.gradle может быть расширена с помощью служебного подпроекта buildSrc внутри проекта, а также подключаемых модулей — плагинов. Плагины подразделяются на встроенные и сторонние. Сторонние плагины можно найти на официальном сайте.

Как скачать и установить Gradle

Для получения дистрибутива нужно перейти на официальный сайт Gradle на страницу релизов и скачать последнюю версию.

Есть два варианта дистрибутива:

• binary-only — только двоичные файлы, достаточные для работы;
• complete — те же файлы, что и в первом варианте, плюс документация и исходный код.

Для установки достаточно распаковать содержимое zip-архива в любую доступную папку.

Чтобы запустить Gradle, нужно указать в командной строке полный путь до файла gradle (для Linux и MacOS) или gradle.bat (для Windows).

Для более простого использования можно создать переменную окружения GRADLE_HOME, указывающую путь с распакованным дистрибутивом, и добавить папку $GRADLE_HOME/bin/ (для Linux и MacOS) или %GRADLE_HOME%\bin\ (для Windows) к переменной PATH.

Java-разработчик

Java уже 20 лет в мировом топе языков программирования. На нем создают сложные финансовые сервисы, стриминги и маркетплейсы. Освойте технологии, которые нужны для backend-разработки, за 14 месяцев.