Конфигурация Gradle

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

1. Технология

Gradle — это инструмент с открытым исходным кодом для автоматического управления задачами. Он основан на концепции Apache Ant, Apache Maven. Gradle разработан с использованием языка Groovy. Gradle разработан с использованием Groovy на основе предметно-ориентированного языка (DSL). Сборка Gradle содержит задачи на языке Groovy, такие как Apache Maven, а файл сборки Apache Ant имеет формат XML.

Gradle использует направленный ациклический граф (DAG) для определения порядка выполнения задач. Gradle был разработан для многопроектных сборок, что означает, что в одном проекте будет много дочерних проектов, число которых может возрасти до большого. Уникальная особенность Gradle состоит в том, что он поддерживает инкрементные сборки, разумно определяя, какие части дерева сборки были изменены, а какие нет. Если некоторые части дерева не будут изменены, оно будет пропущено при обновлении, другие будут выполнены повторно, что сократит время сборки проектов.

2. Структура проекта Java

Подобно структуре каталогов Maven, Gradle — это структура проекта, которая также будет содержать ресурсы src / main / java и src / main / для классов Java и ресурсов пути к классам, src / test / java и src / test / resources будут содержать тестовые классы и проверить ресурсы соответственно.

3. Конфигурация Gradle

Gradle является фундаментальной концепцией для определения зависимостей. Используя Конфигурацию, мы использовали для указания зависимостей, которые могут находиться в локальном кэше, в Maven Central Repository или в любом репозитории, настроенном в файле сборки Gradle.

Gradle также поддерживается при выполнении файла сборки Maven (pom.xml) и файла сборки ant (build.xml) путем его импорта в файл сборки Gradle (build.gradle).

По умолчанию Gradle поддерживает следующие конфигурации:

3.1. реализация

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

a) Gradle добавляет зависимость в путь к классам компиляции и упаковывает зависимость в выходные данные сборки. Однако, когда ваш модуль настраивает зависимость реализации, он сообщает Gradle, что вы не хотите, чтобы модуль пропускал зависимость от других модулей во время компиляции. То есть зависимость доступна для других модулей только во время выполнения.

б) Использование этой конфигурации зависимостей вместо API или компиляции (не рекомендуется) может привести к значительному улучшению времени сборки, поскольку уменьшает количество модулей, которые система компиляции должна перекомпилировать. Например, если зависимость реализации меняет свой API, Gradle перекомпилирует только эту зависимость и модули, которые напрямую зависят от нее. Большинство приложений и тестовых модулей должны использовать эту конфигурацию.

3.2. API

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

a) Gradle добавляет зависимость к пути к классам компиляции и создает выходные данные. Когда модуль включает в себя зависимость API, он сообщает Gradle, что модуль хочет транзитивно экспортировать эту зависимость в другие модули, чтобы он был доступен им как во время выполнения, так и во время компиляции.

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

3.3. compileOnly

Конфигурация compileOnly позволяет объявлять зависимости, которые должны быть доступны только при компиляции, а не во время выполнения. Например, Project, Lombok — это библиотека, которая изменяет байт-код во время компиляции и добавляет дополнительные методы в класс, используя аннотации. Как только обновленный байт-код сгенерирован, его не нужно представлять в пути к классам, поскольку эти типы библиотек будут использовать эту конфигурацию.

3.4. Только время выполнения

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

3.5. процессор аннотаций

Чтобы добавить зависимость от библиотеки, которая является процессором аннотации, вы должны добавить ее в путь к классу процессора аннотаций, используя конфигурацию процессора аннотаций. Это связано с тем, что использование этой конфигурации повышает производительность сборки, отделяя путь к классам компиляции от пути к классам процессора аннотаций. Если Gradle находит процессоры аннотаций в пути к классам компиляции, он деактивирует предотвращение компиляции, что отрицательно влияет на время сборки (Gradle 5.0 и выше игнорируют процессоры аннотаций, найденные в пути к классам компиляции).

3,6. тестовая реализация

Подобно конфигурации реализации, конфигурация реализации теста используется для указания зависимостей, которые доступны во время компиляции и выполнения тестов. Например, библиотеки Junit и Mocking необходимы только при компиляции или выполнении тестов.

3,7. testCompileOnly

Аналогично компиляции Только зависимости доступны только при компиляции тестового класса, но не во время выполнения тестов.

3,8. testRuntimeOnly

Подобно runtimeOnly, эти зависимости доступны при выполнении тестов, но не при компиляции тестов.

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

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

4. Конфигурация Gradle — Заключение

В текущем блоге мы узнали об инструменте сборки Gradle и добавили преимущества Gradle по сравнению с инструментами сборки Maven, Ant. Мы подробно рассмотрели конфигурацию Gradle, где можно указать зависимости на каждом уровне конфигурации.

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