Управление зависимостями в Gradle

1. Обзор

В этом руководстве мы рассмотрим объявление зависимостей в скрипте сборки Gradle. Для наших примеров мы будем использовать Gradle 6.7 .

2. Типичная структура

Начнем с простого скрипта Gradle для Java-проектов :

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'
    testImplementation 'org.springframework.boot:spring-boot-starter-test:2.3.4.RELEASE'
}

Как видно выше, у нас есть три блока кода: плагины , репозитории и зависимости .

Во-первых, блок plugins говорит нам, что это Java-проект. Во-вторых, блок зависимостей объявляет версию 2.3.4. ВЫПУСК зависимости spring-boot-starter , необходимой для компиляции исходного кода проекта. Кроме того, в нем также говорится, что для компиляции набора тестов проекта требуется spring-boot-starter-test .

Сборка Gradle извлекает все зависимости из репозитория Maven Central, как определено в блоке репозиториев .

Давайте сосредоточимся на том, как мы можем определить зависимости.

3. Конфигурации зависимостей

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

3.1. Как объявить зависимости

Для начала конфигурация состоит из 4 частей:

• group – идентификатор организации, компании или проекта
• имя — идентификатор зависимости
• версия — та, которую мы хотим импортировать
• классификатор — полезен для различения зависимостей с одной и той же группой , именем и версией.

Мы можем объявлять зависимости в двух форматах. Контрактный формат позволяет нам объявить зависимость как строку :

implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'

Вместо этого расширенный формат позволяет нам записать его как карту :

implementation group:

'org.springframework.boot', name: 'spring-boot-starter', version: '2.3.4.RELEASE'

3.2. Типы конфигурации

Кроме того, Gradle предоставляет множество типов конфигурации зависимостей:

• api — используется, чтобы сделать зависимости явными и показать их в пути к классам. Например, при реализации библиотеки, чтобы она была прозрачна для потребителей библиотеки.
• реализация — требуется для компиляции производственного исходного кода и является чисто внутренним. Они не выставляются за пределы пакета
• compileOnly — используется, когда их нужно объявить только во время компиляции, например, аннотации только для исходного кода или обработчики аннотаций. Они не отображаются в пути к классам среды выполнения или пути к классам теста.
• compileOnlyApi — используется, когда это требуется во время компиляции и когда они должны быть видны в пути к классам для потребителей.
• runtimeOnly — используется для объявления зависимостей, которые требуются только во время выполнения и недоступны во время компиляции
• testImplementation — требуется для компиляции тестов
• testCompileOnly — требуется только во время компиляции теста
• testRuntimeOnly — требуется только во время выполнения теста

Следует отметить, что последние версии Gradle устарели для некоторых конфигураций, таких как compile , testCompile , runtime и testRuntime. На момент написания они все еще доступны.

4. Типы внешних зависимостей

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

4.1. Зависимости модуля

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

По сути, Gradle извлекает зависимости из указанного репозитория внутри блока репозитория :

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter:2.3.4.RELEASE'
}

4.2. Файловые зависимости

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

Для этой цели мы можем использовать файлы для включения коллекции зависимостей:

dependencies {
    runtimeOnly files('libs/lib1.jar', 'libs/lib2.jar')
}

Точно так же мы можем использовать файловое дерево для включения иерархии файлов jar в каталог:

dependencies {
    runtimeOnly fileTree('libs') { include '*.jar' }
}

4.3. Зависимости проекта

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

Допустим, мы хотим объявить, что наш проект зависит от общего проекта:

dependencies { 
    implementation project(':shared') 
}

4.4. Зависимости Gradle

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

dependencies {
    implementation gradleApi()
}

5. скрипт сборки

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

Ниже мы заявляем, что хотим использовать плагин Spring Boot , загрузив его с Maven Central:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.3.4.RELEASE' 
    }
}
apply plugin: 'org.springframework.boot'

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

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

plugins {
    id 'org.springframework.boot' version '2.3.4.RELEASE'
}

6. Заключение

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

Учитывая эти моменты, исходный код этой статьи доступен на GitHub .