Коротке знайомство з Gradle

Вступ

Темою цього огляду буде система автоматичного складання Gradle. Англійською системи збірки називаються Build Tools . Навіщо це взагалі потрібно? Ручне складання проектів на Java досить трудомісткий процес. Потрібно правильно вказати потрібні проекту бібліотеки та фреймворки, від яких проект залежить. Тут можна прочитати чудову статтю на хабрі: Робота з Java в командному рядкуРано чи пізно ви почнете створювати якісь скрипти для автоматизації цього процесу. А тепер уявіть, що так роблять усі розробники по всьому світу і кожен пише заново те, що хтось уже написав для свого проекту. збирання проектів, які автоматизують цей процес, крім того, дозволяють з одного боку зібрати Вам проект так, як Ви цього хочете, з іншого боку надають вам більш-менш стандартизовані кошти Альтернативою Gradle є система автоматичного збирання Maven. різні, а з іншого боку мають і низку подібностей.На цю тему на сайті Gradle є матеріал: Migrating from Maven to GradleЯк сказано в цьому посібнику, Gradle і Maven мають різницю у погляді на те, як збирати проект. Gradle заснований на графі завдань (task), які можуть залежати один від одного. Завдання виконують якусь роботу. фаз (phase), до яких приєднуються певні "мети" (goals).В цих goals і виконується якась робота. Однак, при таких різних підходах обидві системи складання слідують одній угоді і управління залежностями відбувається схоже. Щоб почати використовувати Gradle необхідно його завантажити У google або yandex вводимо "Gradle Build Tool" і в перших результатах бачимо офіційний сайт: https://gradle.org На головній сторінці Gradle є посилання з текстом "Docs", яка веде на документацію Gradle. Для початку нам потрібно встановити (Install) Gradle, тому нам цікавий розділ документації " Installing Gradle ". Існує безліч способів установки, у тому числі спосіб "по-старому", тобто. вручну (" Installing manually "). Завантажуємо згідно інструкції файл типу " binary-only ", який матиме назву виду gradle-5.1.1-bin.zip. Далі розпаковуємо архів і налаштовуємо змінне середовище оточення PATH згідно з інструкцією. Головне, після виконання інструкції команда gradle -vпоказує версію Gradle. Може виникнути проблема з тим, що для визначення розташування система знайде Gradle не там, де Ви хочете. Тому на Windows можна виконати (на *nix є свої аналоги): for %i in (gradle.bat) do @echo. %~$PATH:i Тепер, мабуть, можна розпочинати знайомство.

Ініціалізація проекту Gradle

Відразу хочеться відзначити, що Gradle - це для виконання завдань, званих task (я називатиму їх тягами). Таски надаються різними плагінами ( plugins ). Детальніше про плагіни раджу прочитати в офіційній документації: " Using Gradle Plugins ". Є набір "Core Plugins", які завжди, коли встановлений Gradle. Є різні категорії цих плагінів, але нас цікавить категорія " Utility ". У цьому наборі є плагін " Build Init Plugin ", який надає таски для ініціалізації (Initialization) Gradle проекту. Нас цікавить створення типу проекту: " java-application ". Виконаємо Gradle таск: gradle init --type java-application Відповімо принагідно на деякі питання, наприклад про те, що ми хочемо використовувати Groovy DSL (стандартна мова опису завдань для Gradle) та фреймворк тестування JUnit (про це ми поговоримо в іншому огляді). Після створення ми отримаємо наступний набір файлів: По-перше, після ініціалізації ми отримуємо налаштований на нашу версію Gradle спеціальний враппер – це такий спеціальний скрипт. Про нього докладніше раджу прочитати в офіційній документації - The Gradle Wrapper . По-друге, бачимо Gradle Build Script – файл build.gradle. Це головний файл, в якому описується те, які бібліотеки та фреймворки використовує наш проект, які плагіни потрібно підключити до проекту та описує різні таски. Докладніше про цей файл раджу прочитати в офіційній документації: " Build Script Basics ".

Plugins та Tasks

Якщо подивитися зараз на вміст Build Script, то побачимо секцію plugins:

plugins {
    id 'java'
    id 'application'
}

Це ті самі плагіни, про які ми говорабо раніше. А якщо є плагіни, то є й завдання, які нам тепер доступні. Ми можемо виконати команду gradle tasks та побачити, що ми зараз можемо зробити з проектом: Наприклад, виконавши gradle runми запустимо main клас нашого java програми: Як ми бачимо, знизу написано так само. 2 actionable tasks: 1 executed, 1 up-to-date Що це означає? Це означає, що було виконано 2 тяга: Причому 1 справді виконаний, а не виконувався, т.к. він up-to-date, тобто стан актуальний і нічого виконано не було. Ми можемо виконати так званий Dry Run: gradle run -m Виконаємо цю команду, ми побачимо, які будуть виконані таски, щоб виконати таск run: Як ми бачимо, всього було виконано цілих 4 завдання: перш ніж виконався run він виконав залежно від таск classes. Тас classes сам має 2 залежності і тому він виконав ще й compileJava і processResources. Коли ми виконуємо завдання, ми можемо виконати її з переглядом певного рівня логів (рівень логування визначає, наскільки важливі повідомлення хочемо бачити). Наприклад, ми можемо виконати gradle run -i. Це нам буде показувати зокрема інформаційні повідомлення виду:

Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.

Докладніше про логування в Gradle раджу звернутися до офіційної документації: " Gradle Logging ". Як бачимо, таск classes був пропущений, оскільки він UP-TO-DATE , тобто стан актуальне, нічого робити треба, тому дій був (no actions). Це через те, що за замовчуванням у Gradle є " Up-to-date checks " або так званий інкрементальний білд. Докладніше про цей механізм можна почитати в документації Gradle: " Up-to-date checks (AKA Incremental Build) ". Але цей механізм можна вимкнути, виконавши таск із зазначенням прапора --rerun-tasks. Наприклад, gradle run --rerun-tasks. Тоді ми побачимо: 2 actionable tasks: 2 executed Як бачимо, кількість виконаних тягів враховує лише перший рівень графа, тобто сам таск run і ті таски, яких він безпосередньо залежить, тобто classes. Таски, від яких залежить classes тут не рахуються (хоча вони і виконуються, коли виконується таск classes). Про завдання також слід прочитати:

• " Authoring Tasks ": Визначає створення своїх завдань.
• " Writing Custom Gradle Tasks ": Посібник step by step зі створення завдань.
• " Build Script Basics ": Основа для завдань та їх використання.

Dependencies

Однією з головних завдань будь-якої системи збирання є управління залежностями, тобто тим, які бібліотеки/фреймворки потрібні нашому проекту. Система складання повинна забезпечити їх наявність у потрібний момент та належним чином зібрати кінцевий артефакт нашої програми. За замовчуванням після gradle init для java-application ми побачимо наступний вміст у білд-скрипті:

dependencies {
    implementation 'com.google.guava:guava:26.0-jre'
    testImplementation 'junit:junit:4.12'
}

Тут одразу зрозуміло, що ми підключаємо. Але без певного розуміння незрозуміло, що за впровадження і випробуваннявиконання? Тут треба знову звернутися до документації Gradle, благо документація у Gradle написана чудово. Називається це " Managing Dependency Configurations ". Як сказано у документації, кожна залежність оголошується з деяким scope - областю, у межах якої ця залежність буде доступна. Цей скоуп (scope) і визначається деякою конфігурацією (configuration), кожна з яких має унікальне ім'я. Також цікаво, що безліч Gradle плагінів додають передзадані конфігурації. Щоб дізнатися, які у нас конфігурації можна виконати: gradle --console plain dependencies Таким чином ми побачимо список усіх доступних конфігурацій і залежностей, що відносяться до них. Ми можемо відфільтрувати цей список так, щоб бачити лише доступні конфігурації: gradle --console plain dependencies | find " - " Як же зрозуміти, що нам використовувати? Тут трохи доведеться почитати. Т.к. ми використовуємо плагін "Java", то почнемо з його документації та розділу " Dependency management ". Тут бачимо, що була конфігурація (він же скоуп), звана " compile " і позначала " залежність, необхідна під час компіляції " . Але потім його замінабо (англ. Superseded) на implementation. Докладніше про заміну можна прочитати в розділі " API and implementation separationВиходить, ця залежність буде на "compile classpath". Але іноді ми хочемо, щоб наша залежність була включена до підсумкового артефакту. Навіщо? Наприклад, у нас буде виконуваний jar, який повинен сам у собі містити все необхідне. Що ж тоді нам По-перше, такої підтримки "з коробки" (тобто за замовчуванням, без будь-яких додаткових дій) немає, пояснюється це тим, що кожен хоче архів зібрати по своєму, а Gradle намагається бути мінімалістичним. використовувати jar архіви на classpath (без додаткових маніпуляцій у коді), тому що це так не працює (Докладніше див. " Oracle: Adding Classes to the File Class's JAR").

jar {
    manifest {
        attributes 'Main-Class': 'jrgradle.App'
    }
    from configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}

У налаштуваннях таска jar ми вказуємо те, що буде додано в маніфест jar-файлу (див. " Oracle: Setting an Application's Entry Point "). А далі ми кажемо, що всі залежності, які були потрібні для компіляції, ми їх включимо в jar. Альтернативою може послужити використання плагіна " Gradle Shadow Plugin ". Може здатися складним, але інші плагіни можуть спрощувати життя. Наприклад, при створенні веб-програми (на відміну від звичайної програми, що виконується) ми будемо використовувати особливий плагін - " Gradle War Plugin", який має іншу поведінку і там життя наше буде простіше (всі потрібні залежності будуть складені в окремий особливий каталог самим плагіном. Така робота регламентується тим, як мають бути влаштовані веб-додатки. Але це вже зовсім інша історія)".

Підсумки

Gradle – є відмінним вибором як системи складання проектів. Підтвердженням цього є те, що його використовують розробники таких відомих проектів як Spring та Hibernate. Вище були розглянуті лише базові речі. За ними прихований мільйон особливостей та можливостей, які з'являються у розробників. Gradle також підтримує створення багатомодульних проектів, що не розглянуто в даному огляді, але є відмінний tutorial у самого Gradle: Creating Multi-project BuildsСподіваюся, цей огляд також продемонстрував, що документація у Gradle написана на 5+ і по ній легко можна знайти потрібне, якщо розуміти, куди приблизно дивитися. А це прийде, коли розумієш основи. Крім того, у Gradle шикарні tutorial. хочеться невеликим списком того, що ще можна подивитися по Gradle:

• Gradle Training (Часто безкоштовні).
• Gradle for Android and Java
• Building Java Web Applications
• Євген Борисов - Power of Gradle (2013)

#Viacheslav