Gradle *

Интересная заметка от Madis Pink в блоге ZeroTurnaround RebelLabs. Если кто-то вас разбудит посреди ночи и спросит: «какую фичу в Gradle должен знать каждый?» — с уверенностью отвечай, что это buildSrc. Это особый магический Gradle-проект внутри твоего репозитория, доступный всем файлам build.gradle в виде библиотеки.

Описанный далее подход позволяет писать код на удобном тебе JVM-языке, и результат использовать прямо в своих сборочных скриптах. Как бонус, можно покрыть юнит-тестами особо хитрые моменты в этих скриптах. Добро пожаловать под кат!

• предпроцессоры;
• системы проверки стиля исходников или всего проекта (lint, checkstyle и т.д.);
• методики разработки, основанные на тестах, с их запуском при сборке;
• различного типа стенды;
• системы развёртывания на базе облачных технологий и т.д. и.т.п.

Введение

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

Ранее у меня был домашний проект (хотя скорее даже его прототип), который было решено переписать на микросервисы. Проект представлял собой попытку сделать обучающую Java игру. То есть у игрока есть поле, на этом поле он может управлять каким-то юнитом с помощью кода. Пишет код, отправляет на сервер, там он выполняется и возвращает результат, который отображается пользователю.

Всё это было реализовано в виде прототипа — были пользователи, один урок и одна задача для него, возможность отправить код, который компилировался и исполнялся. Кое-какой фронтенд, но в статье о нём речи не будет. Технологии — Spring Boot, Spring Data, Gradle.

В статье будет реализован такой же прототип, но уже на микросервисах. Реализация будет наиболее простым путём (точнее наиболее простым, из известных мне). Реализация будет доступна любому, кто знаком со Spring.

Преамбула

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

Композитные сборки

В готовящейся к релизу версии 3.1 в Gradle появляется новый поход к организации сборок, состоящих из нескольких компонентов: композитные сборки (ориг. Composite Builds).

Композитные сборки позволяют:

• Быстро подложить исправленную версию исходников библиотеки в другой проект без необходимости собирать её, опубликовывать и править сборку.
• Делить большие проекты на несколько небольших, изолированных сборок, над каждой из которых можно работать как по отдельности, так и одновременно.
• Отделить разработку плагина для системы сборки от проекта, его использующего (аналог buildSrc)

Как-то при подготовке одного из докладов про разработку плагинов для Gradle встала задача — как свои поделия потестировать. Без тестов вообще жить плохо, а когда твой код реально запускается в отдельном процессе и подавно, потому что хочется дебага, хочется быстрого запуска и не хочется писать миллион example-ов, чтобы протестировать все возможные кейсы. Под катом сравнение нескольких способов тестирования, которые мы успели попробовать.

def password = System.console().readPassword("\nPlease enter key passphrase: ")