Используем gradle и github actions для публикации java проекта в sonatype maven central repository

Многомодульный Java-проект с Gradle. Шаг за шагом

Tutorial

Очень много статей о Gradle написано. И со своей стороны хотелось бы добавить в копилку такую пошаговую инструкцию, прочтение которой, я надеюсь, позволит тем, кто плохо знаком с Gradle, “распробовать” и продолжить самостоятельно изучать этот инструмент.
Данная статья не будет подробно описывать такие темы, как плагины gradle (plugin), задачи (task), зависимости (dependencies), автоматическое тестирование и прочие прелести этого сборщика проектов. Во-первых, каждая тема заслуживает отдельной статьи или даже серии статей, а во-вторых, на эти темы уже есть статьи на хабре, например: Gradle: Tasks Are Code, Gradle: Better Way To Build. А еще на официальном сайте Gradle есть прекрасно написанный Gradle User Guide

Я же cфокусирую внимание на непосредственном решении поставленной задачи, и все сопутствующие темы будут описаны в рамках этой самой задачи.
Сначала определимся с целью, что же мы хотим получить на выходе? А цель указана в заголовке статьи. Мы хотим получить проект с несколькими модулями, который собирается с помощью Gradle

И так, приступим.

Gradle: Better Way To Build

Ни один проект с использованием платформы Java (и не только) не обходится без инструментов сборки (если только это не «Hello, world!»). Рано или поздно, но собирать дистрибутив руками надоедает. Да и компилировать из консоли было бы неплохо, если в проекте используется несколько разных IDE. А перед сборкой дистрибутива было бы здорово проставить номер версии в его имени. И unit тесты прогнать — не зря же Kent Beck книжки пишет. А там и Continues Integration на горизонте маячит. И здорово было бы научить CI сервер это все делать самостоятельно. Одним словом, есть уйма задач.
Раз есть задачи, то есть и решения. Думаю, большинство разработчиков хоть раз, но сталкивались с Ant. Очень многие используют Maven. Есть другие, не такие распространённые инструменты: GAnt, Buildr, и др. Каждый из них обладает набором своих плюсов и минусов, но сегодня я хочу представить вам кое-что новенькое. Gradle.

Трансформация кода в Android 2. Анализ AST

• Первая часть
• Пример на Github

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

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

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

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

Сборка Java кода

Начнем с простого, создадим очень простой в корневой папке проекта(там,
где src), который содержит только одну строчку:

Эта единственная строчка в конфигурации сборки приносит значительную пользу. Запустите gradle tasks
снова и вы увидите новые задачи в списке, включая задачи для сборки проекта, создания JavaDoc и запуска тестов.

Вы будете изпользовать задачу gradle build достаточно часто. Эта задача компилирует, тестирует и
упаковывает код в JAR-файл. Вы можете запустить её таким образом:

Через несколько секунд, «BUILD SUCCESSFUL» будет означать, что сборка прошла успешно.

Чтобы увидеть результаты сборки, посмотрите на содержимое каталога build. Здесь
вы найдете несколько директорий, среди которых три наиболее значимые:

• classes. Скомпилированные .class файлы
• reports. Отчеты в течении сборки(такие как отчеты о тестировании)
• libs. Библиотеки для сборки проекта(обычно в виде JAR и/или WAR файлов)

Классы в каталоге с .class файлами генерируются во время сборки Java-кода. Соответственно,
вы должны найти там HelloWorld.class и Greeter.class.

На данный момент проект не имеет зависимостей от библиотек, поэтому ничего нет в папке dependency_cache.

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

Каталог библиотек должен содержать JAR-файл с названием каталога проекта. В дальнейшем, вы увидите,
как указывать имя JAR-файла и его версию.

Свой плагин

Подобно задаче, можно написать свой плагин, который будет что-то настраивать или создавать задачи. Например, происходящее в — полностью заслуга тёмной магии андроид плагина, который вдобавок создаёт целую кучу задач типа app:assembleDevelopDebug на все возможные сочетания flavor/build type/dimenstion. Ничего сложного в написании своего плагина нет, для лучшего понимания можно посмотреть код других плагинов.

Есть ещё третья ступенька — можно код расположить не в , а сделать его отдельным проектом. Потом с помощью https://jitpack.io или ещё чего-то опубликовать плагин и подключать его аналогично остальным.

Боитесь ли вы Gradle так как боюсь его я?

Скажу сразу — в Gradle я совсем новичок.
Пол рабочего дня, вместо того, чтоб писать код содержащий мою семью, я потратил на то, чтобы узнать что из 150-ти строк конфига, надо было исправить одну, поменяв на .
Программа вчера запускалась а сегодня перестала. А знаете что я сегодня сделал не так? А ничего. Абсолютно тот же код и те же конфиги. Ни одного файла не менял.
Смышленый или опытный программист уже догадался что знак «+» — значит что надо загрузить самую последнюю версию библиотеки и загрузилось что то не то. Да это часть проблемы, но не вся. Сама библиотека ничего не портила. Она просто имела зависимость от другой — которая портила.
Да и вообще, что за мода выкладывать не оттестированные библиотеки в общий репозиторий? При Мавене такого не было!

Трансформация кода в Android

Из песочницы

Вместо вступления

Всё началось с того, что мне захотелось изучить тонкости настройки Gradle, понять его возможности в Android разработке (да и вообще). Начал с жизненного цикла и книги, постепенно писал простые таски, попробовал создать свой первый Gradle плагин (в ) и тут понеслось.

Решив сделать что-то, приближенное к реальному миру Android разработки, написал плагин, который парсит layout xml файлы разметки и создает по ним Java объект со ссылками на вьюхи. Затем побаловался с трансформацией манифеста приложения (того требовала реальная задача на рабочем проекте), так как после трансформации манифест занимал порядка 5к строк, а работать в IDE с таким xml файлом довольно тяжело.

Так я разобрался как генерировать код и ресурсы для Android проекта, но со временем захотелось чего-то большего. Появилась мысль, что было бы круто трансформировать AST (Abstract Syntax Tree) в compile time как это делает . Такое метапрограммирование открывает много возможностей, была бы фантазия.

Дабы теория не была просто теорией, я решил подкреплять изучение темы созданием чего-то полезного для Android разработки. Первое, что пришло на ум — сохранение состояния при пересоздании системных компонентов. Грубо говоря, сохранение переменных в Bundle максимально простым способом с минимальным бойлерплейтом.

Добавляем свои данные в ресурсы

Принцип точно такой же, что и с BuildConfig, но позволяет добавлять значения в файл ресурсов. Но зачем добавлять ресурс из конфига, если проще это сделать, как обычно, в XML-файле? Просто потому, что в скрипте, так же как и в случае с BuildConfig.TIMEOUT, значение ресурса можно вычислить. Например, сохранить дату сборки:

Gradle создаст специальный файл generated.xml примерно такого содержания (только, разумеется, с правильными угловыми скобочками):

И пусть тебя не смущает, что мы храним время в формате String. К сожалению, Android SDK не умеет хранить в ресурсах long, а в 32-битный integer время не влезет.

Полезные ссылки

• Официальная документация Довольно объёмная, но местами может не хватать подробностей.
• исходники на github, javadoc — из-за динамической типизации в groovy среда разработки далеко не всегда может выдать список доступных полей/методов, а по коротким названиям методов и типам аргументов (Closure closure) не всегда можно понять, зачем они нужны.
• статья на хабре с кучей примеров — это перевод второй главы книги «Building and testing with gradle». Книжку тоже можно почитать, она находится в свободном доступе.
• ещё одна статья — про buildSrc

Консоль

Android studio/IDEA старательно прячет команды gradle от разработчика, а ещё при изменении build.gradle файликов начинает тупить или перезагружать проект.

В таких случаях вызывать gradle из консоли оказывается намного проще и быстрее. Враппер для gradle обычно идёт вместе с проектом и прекрасно работает в linux/macos/windows, разве что в последнем надо вызывать bat-файлик вместо враппера.

More memory efficient Gradle execution

Features like for tests and command-line arguments for JVM apps allow for better dev workflows, while lower memory requirements and cache cleanup reduce Gradle’s overhead on your system.

Lower memory requirements

Not only will your builds be faster just by upgrading, but they’ll also use significantly less memory.
Many caching mechanisms have been optimized in Gradle 5.0, and as a result the default maximum memory for Gradle processes .

Process Type	Gradle 4.x default heap	Gradle 5.0 default heap
Command-line client	1 GB	64 MB
Gradle Daemon	1 GB	512 MB
Worker processes	1/4 of physical memory	512 MB

Periodic Gradle cache cleanup

The days of manually cleaning up gigabytes of old Gradle caches are over. Gradle now periodically.
Gradle also tracks stale task outputs more precisely, and cleans them up in cases where not doing so could lead to incorrect results.

Как подружился Ebean с Gradle и помирился с IntelliJ Idea

Из песочницы

Наконец-то я созрел, чтобы начать свой веб-проект. Очередной todo-менеджер, который агрегирует задачи с нужных мне источников. Планировался как проект для души, такой чистый и правильный. Никаких компромиссов в архитектуре и технологиях. Только best-practices, только хардкор. И, конечно же, кнопать это все собрался в любимой Intellij IDEA.
После 7 лет Java, последних двух вперемешку с Scala, захотелось попробовать Groovy. Для сборки, конечно же Gradle — популярно и удобно. Рельсы показались слишком «заезженные», так что решил использовать Spring для веб, причем по современному, через Spring Boot. И все было просто замечательно, только с ORM не сложилось. На работе мы Hibernate выпилили, заказчик лично невзлюбил (не смейтесь и такое бывает — отдельная история) и заменили своим велосипедом. Негативный опыт и нежелание тянуть монстра ради пары сущностей сделали свое — хибернейту твердое нет! Захотелось попробовать что-то совсем другое. По воле случая наткнулся на Ebean, который и был выбран.
После окончательной подборки стека начала кипеть работа. Но вот незадача, воз с функционалом пока не сдвинулся с места. Под катом искреннее оправдание почему.

Кросс-компиляция Scala в Gradle проекте

Из песочницы

Для Scala проектов довольно распространённым является предоставление бинарных артефактов скомпилированных под несколько версий Scala компилятора. Как правило для целей создания нескольких версий одного артефакта в сообществе принято использовать SBT, где эта возможность есть прямо из коробки и настраивается в пару строк. Но что если мы хотим заморочится и создать билд для кросс компиляции не используя SBT?

Для одного из своих Java проектов я решил создать Scala фасад. Исторически весь проект собирается с помощью Gradle, и фасад было решено добавить в этот же самый проект в качестве сабмодуля. Gradle в целом может компилировать Scala модули с той лишь оговоркой что никакой кросс компиляции в поддержке не заявлено. Есть открытый тикет 2017 года и пара плагинов (, ), которые обещают добавить эту возможность в ваш проект, но с ними есть проблемы, как правило связанные с публикацией артефактов. И больше в целом ничего нет. Я решил проверить, как сложно на самом деле сконфирурировать билд для кросс компиляции без специальных плагинов и СМС.

Android Gradle plugin

Gradle сам по себе ничего не знает о том, как билдить Android-проект, в этом ему помогает плагин, который разрабатывается вместе с Android SDK. Если ты только недавно начал осваивать программирование под Android, то мог и не заметить, что в главном сборочном скрипте студия самостоятельно добавляет зависимость от этого плагина.

А в скрипте твоего основного модуля этот плагин автоматически подключается строчкой . Именно поэтому у тебя в скрипте есть секция , в которой ты указываешь версию Build Tools, версии SDK для сборки и прочее.

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

Переупаковка пакетов в Gradle

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

К сожалению, это не всегда помогает решить проблему конфликта версий. Например, есть известная проблема, что некоторые устройства htc в прошивке уже имеют библиотеку gson и если ваша версия gson-а отличается от встроенной, то могут возникнуть проблемы, так как ClassLoader загрузит в память только один класс и в данном случае это будет системный.

Такая проблема также может возникнуть и при разработке библиотек. Если вы подключите в свой проект 2 библиотеки, использующие одну и ту же стороннюю библиотеку разных версий, например 1 и 2, то Gradle разрулит и возьмет самую новую версию, вторую. Но если в этой сторонней библиотеке нет обратной совместимости и вторая версия не может быть просто так использована вместо первой, то будут проблемы, которые наверняка будет очень сложно отследить по стектрейсу. Библиотека, ожидающая первую версию, получит классы второй и просто упадет.

Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала. После написания плагина, я проверил его работоспособность на тестовом проекте: все отлично, проверил на pet project-е, тоже все хорошо, но когда подключил к реальному рабочему проекту с кучей сторонних зависимостей, столкнулся с проблемой.

Решение проблемы под катом.

Лайфхаки

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

1. Используйте консоль. Найти команды иногда бывает проблематично, а при изменении build.gradle система может заглючить или, вообще, перезагрузить проект. Поэтому специалисты рекомендуют вызывать Gradle прямо из консоли.
   Враппер обычно идёт вместе с проектом. На Linux и macOS можно обращаться напрямую. На Windows — вызывать вместо враппера bat-файл.

2. Gradle хранит кэш 1 сутки. Это можно перенастроить. Необходимо отредактировать код:

3. – –refresh-dependencies — полезная команда, которая запустит обновление всех зависимостей в Gradle. Может пригодиться, если какие-то данные в кэше повредились, так как верифицирует. Удобно использовать при повреждении данных кэша, так как происходит их верификация и обновление (если отличаются).

4. Используйте CI (непрерывную интеграцию) в работе с системой автоматической сборки. Пусть модульные тесты выполняются для всех коммитов. Также специалисты рекомендуют подключать и unit-тесты. Это можно сделать в Android Studio.
   Такая комбинация позволит обнаружить ошибки раньше. И хотя она замедлит процесс запуска, разработчик сможет отдохнуть в дальнейшем. Так что лайфхак на перспективу.

5. Try again. Страшно? (Нам тоже) На самом деле синхронизацию не всегда нужно сразу запускать заново. Сначала специалисты рекомендуют проверить систему в целом. Например, с помощью любой простой команды — это поможет понять, каковы шансы на успех следующей синхронизации.

6. Настройте с Gradle среду разработки IntelliJ IDEA. Это позволит оптимизировать процесс работы, а также воспользоваться волшебным списком.

7. Совет для тех, кто работает с Gradle из командной строки Android Studio. Проверьтесь на ошибку «Starting a Gradle Daemon, 1 incompatible could not be reused» (#68374709). Это бич системы, который разработчики пока не исправили.

Одна из основных проблем Gradle — «Gradle build failed». Обойдёмся без лишних слов, если вам это уже знакомо. Если же нет — удачи.

Впрочем, главная проблема Gradle другая. Время, которое требуется системе на сборку, уже давно стало (очень печальной) легендой в кругах специалистов. Ускорить работу нельзя, по крайней мере — значительно.

Так что придётся ждать в любом случае.

Можете, например, слетать куда-нибудь в космос, как в «Интерстеллар».

Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов

С переездом из SVN на GIT и gitlab (плюс переезд из Jenkins на Gitlab-CI, но его использование также упомянём), встал вопрос версионирования получаемых артефактов сборки приложения.
В SVN был всем привычный номер ревизии, монотонно увеличивающийся с каждым коммитом. Его было удобно добавлять в номер версии, и это решало большинство проблем. Но git конечно предоставляет множество плюшек, и стоило убеждать руководство и всё команду перевести проект на него…
Зато пришлось отстроить заново процесс версионирования получаемых артефактов сборки.
В итоге остановились на очень хорошем Gradle плагине github.com/nemerosa/versioning, о его использовании я и собираюсь рассказать.

Gradle: Tasks Are Code

В предыдущем топике я постарался вкратце рассказать, что же такое Gradle и на каких идеях он построен. Также была освещена концепция Source Sets и функциональность, с ней связанная.
Теперь я хотел бы рассказать о том, чем Gradle зацепил лично меня. Речь пойдёт о способах работы с задачами. Задача в Gradle — близкий аналог Ant Target. И, чтобы не путаться в терминах, под задачей (или task) далее по тексту всегда будет подразумеваться Gradle Task. Если речь будет идти о сущности из Ant, то это будет указано явно: Ant task.
Так вот, задачи в Gradle создаются при помощи специального dsl (domain specific language) на основе Groovy. И возможности, которые этот dsl предоставлет, на мой взгляд, почти безграничны в сравнении с ant или maven.

Multi-release JARs — Плохо или хорошо?

Перевод

От переводчика: мы активно работаем над переводом платформы на рельсы Java 11 и думаем над тем, как эффективно разрабатывать Java библиотеки (такие как YARG) с учётом особенностей Java 8 / 11 так, чтобы не пришлось делать отдельные ветки и релизы. Одно из возможных решений — multi-release JAR, но и тут не всё гладко.

Java 9 включает новую опцию Java-рантайма под названием multi-release JARs. Это, возможно, одно из самых противоречивых нововведений в платформе. TL;DR: мы считаем это кривым решением серьезной проблемы. В этом посте мы объясним, почему мы так думаем, а также расскажем, как вам собрать такой JAR, если вам сильно хочется.

Multi-release JARs, или MR JARs, — это новая функция платформы Java, появившаяся в JDK 9. Здесь мы подробно расскажем о значительных рисках, связанных с использованием этой технологии, и о том, как можно создавать multi-release JARs с помощью Gradle, если вы ещё хотите.

По сути, multi-release JAR — это Java-архив, включающий несколько вариантов одного класса для работы с разными версиями среды исполнения. Например, если вы работаете в JDK 8, среда Java будет использовать версию класса для JDK 8, а если в Java 9, используется версия для Java 9. Аналогично, если версия создана для будущего выпуска Java 10, рантайм использует эту версию вместо версии для Java 9 или версии по умолчанию (Java 8).

Под катом разбираемся в устройстве нового формата JAR и выясняем нужно ли это всё.

Other things you may have missed

There have been lots of changes since Gradle 5.0. Here are some other things you can enjoy in Gradle 6.0.

Bootstrap a new project with

Gradle 6.0 can bootstrap a project with and a few parameters.

You can choose one of these projects:

• An application written in Java, Groovy, Kotlin, C++ or Swift
• A library written in Java, Groovy, Scala, Kotlin, C++ or Swift
• A Gradle plugin written in Java, Groovy or Kotlin
• A basic, empty project

Quickly find the task you want to run by filtering by its group

Gradle 6.0 lets you quickly find tasks by showing only the tasks belonging to a particular group. This makes it easier to find tasks in builds with many available tasks.

Try it out with .

Stay up to date by failing on deprecation warnings

The command line option has a option that will show all deprecation warnings and will fail the build if any deprecation warning is found during the build.

Incremental PMD analysis

Gradle 6.0’s PMD plugin supports using PMD’s incremental analysis cache to improve performance when files have not changed in between builds. To enable incremental analysis, add the following to your PMD configuration:

Executing Java applications with long classpaths

When Gradle detects that a Java process command-line will exceed Windows’s 32,768 character limit, Gradle will attempt to shorten the command-line by passing the classpath of the Java application via a “classpath jar”.

The classpath jar contains a manifest with the full classpath of the application. Gradle will only pass the generated jar on the command-line to the application. If the command-line is still too long, the Java process will fail to start as before.

If the command-line does not require shortening, Gradle will not change the command-line arguments for the Java process.

Artifact Signing

Gradle 6.0 has several signing related improvements:

• The signing plugin uses SHA512 instead of SHA1
• In-memory subkeys are

If you use the or plugins, Gradle will automatically upload SHA256 and SHA512 signatures, in addition to the traditional but unsecure MD5 and SHA1 signatures.

Publication of SHA256 and SHA512 files is not supported by the deprecated maven plugin but works with the legacy uploadArchives task for Ivy repositories.

Dependency Management

Both build systems provide built-in capability to resolve dependencies from configurable repositories. Both are able to cache dependencies locally and download them in parallel.

As a library consumer, Maven allows one to override a dependency, but only by version. Gradle provides customizable and that can be declared once and handle unwanted dependencies project-wide. This substitution mechanism enables Gradle to build multiple source projects together to create composite builds.

Maven has few, built-in dependency scopes, which forces awkward module architectures in common scenarios like using test fixtures or code generation. There is no separation between unit and integration tests, for example. Gradle allows , which provides better-modeled and faster builds.

Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph. In addition, with Gradle you can declare versions as strictly which allows them to take precedence over transitive versions, allowing to .

Шпаргалка по Gradle

Как мне кажется, большинство людей начинают разбираться с gradle только тогда, когда в проекте что-то надо добавить или что-то внезапно ломается — и после решения проблемы «нажитый непосильным трудом» опыт благополучно забывается. Причём многие примеры в интернете похожи на ускоспециализированные заклинания, не добавляющие понимания происходящего:

Я не собираюсь подробно описывать, для чего нужна каждая строчка выше — это частные детали реализации андроид-плагина. Есть кое-что более ценное — понимание того, как всё организовано. Информация раскидана по различным сайтам/официальной документации/исходникам градла и плагинов к нему — в общем, это чуть более универсальное знание, которое не хочется забывать.

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

Faster builds

Slow builds waste a lot of money.
Building only what you need by using the new build cache and incremental processing features in Gradle 5.0 will make developers and business executives happy.

Your builds will already be a bit faster immediately after upgrading to Gradle 5.0, and you can improve their performance further by using and configuring the other features described in this section.

Incremental compile 1000-module Java projectConfiguring Java project w/1000 modules

Build caching

Avoiding work by reusing the results of previous executions makes Gradle fast. Gradle 4.0 introduced the build cache, whose purpose is to reuse outputs from any previous invocation of Gradle.

Today, the plugins for Android, Kotlin, , Scala, and many other plugins have made tasks cacheable and thus reusable across different machines. Effective use of the build cache has been found to reduce build times by up to 90%.

Furthermore, the build cache in Gradle 5.0 is also enabled in more scenarios, such as when a task declares a of or .

Incremental Java compilation

In Gradle 5.0, the incremental compiler is highly optimized and now the default.

This is fantastic news as tasks won’t need to recompile all the source files except the first time with a clean build.

Incremental annotation processing

The incremental compiler in Gradle 5.0 supports , significantly increasing the effectiveness of incremental compilation when annotation processors are present.
This is an important innovation because of the increasing number of projects that rely on annotation processors.

To take advantage of incremental annotation processing, make sure you upgrade to versions of annotation processors that have opted into this feature.
You can find out if a given annotation process is incremental through logging or in this table of popular annotation processors.

Use the to easily manage your annotation processors and put them on the annotation processor path.

Build scans

Build scans have improved dramatically with new inspections for performance, dependency management, logging and the use of deprecated APIs.
This is a free service offered to Gradle users — just add when executing Gradle on the command line or apply and configure the build scan plugin.

Объявление зависимостей

Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек.
Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или
сложного функционала.

К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время.
Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это
и другими интересными способами, например с помощью Joda Time библиотеки.

Во первых, изменим , как показано ниже:

Здесь использует Joda Time класс для получения и печати текущего времени.

Если бы вы запустили для сборки проекта сейчас, то получили бы ошибку сборки,
потому что вы не объявили Joda Time компилируемую зависимость в сборке.

Во-вторых, вам необходимо добавить источники сторонних библиотек:

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

Теперь, когда мы готовы к приему сторонних библиотек, объявим их:

В блоке вы описываете единственную зависимость Joda Time. В частности,
вы запрашиваете(читаем справа на лево) версию 2.2 библиотеки joda-time в joda-time группе.

Другое, что хотелось бы отметить, это необходимость указания ключевого слова , обозначающее
доступность библиотеки во время компиляции(а если бы вы собирали WAR файл, то была бы включена /WEB-INF/libs
папка в WAR). Также существуют другие заметные ключевые слова, среди которых:

• . Требуемые зависимости для компиляции кода, но которые будут
  доступны во время работы кода контейнера(например, Java Servlet API)
• . Зависимости, используемые для компиляции и запуска тестов, но не
  требуемые для компиляции и запуска кода проекта

И наконец, назначим имя для нашего JAR артефакта.

блок определяет, как JAR файл будет назван. В данном случае мы получим .

Теперь, если мы запустим , Gradle должен будет загрузить Joda Time зависимость из
репозитория Maven Central и успешно собрать проект.

Gradle: 5 полезностей для разработчика

Tutorial

Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

How to upgrade

We’ve provided a document to help you upgrade from Gradle 4.x to Gradle 5.0. Before upgrading, we recommend you:

• Upgrade to Gradle 4.10.3 using the Gradle wrapper.

• Run to list all use of deprecated Gradle APIs with their locations, including plugins.
• Update your Gradle plugins, especially those listed in the deprecations report from the build scan.
• Upgrade to JDK 8 or higher, required to run Gradle 5.0.
• See the or reach out on the community forums if you get stuck.

You can share feedback with the Gradle team via @gradle on Twitter. Go forth and Build Happiness!

Compare Gradle vs. Maven
Upgrade Gradle 4.x to 5.0