1. Путь зависимости

Зависимости в Gradle — это прямые зависимости, зависимости проекта и локальные зависимости jar.

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

1.1 Прямая зависимость (зависимость от удаленного склада)

Прямые зависимости — это зависимости, полученные из удаленных репозиториев (например, Maven Central). В Gradle вы можете объявить эти зависимости напрямую по координатам, следующим образом:

dependencies {
    // Прямая Сокращенная форма зависимостииз
    implementation 'cn.hutool:hutool-all:5.8.27'

    // Прямая зависимостьиз полной формы
    iimplementation group: 'cn.hutool', name: 'hutool-all', version: '5.8.27'
}

image-20240420194013517

существоватьMavenизpom.xmlв файле,Это эквивалентно:

<dependencies>
    <dependency>
        <groupId>cn.hutool</groupId>
        <artifactId>hutool-all</artifactId>
        <version>5.8.27</version>
	</dependency>
</dependencies>

существоватьGradleсередина,implementationдаполагаться Конфигурация№1,это эквивалентноMavenсерединаизcompileделатьиспользоватьдомен。

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

Под зависимостью проекта подразумевается существование в многомодульном проекте.,Один модуль зависит от другого модуля. существованиеGradle,ты можешь сделатьиспользоватьprojectметод объявить этополагаться,Как показано ниже:

dependencies {
    // Зависимости проекта
    implementation project(':subject01')
}

image-20240420194227026

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

rootProject.name = 'root'
include 'subject01' // Содержит подмодуль с именем дляsubject01iz.

1.3 Локальные зависимости JAR

Локальные файлы JAR относятся к файлу JAR, который напрямую ссылается на каталог используемого проекта. существованиеGradle,ты можешь сделатьиспользоватьfilesметодилиfileTreeметодобъявить об этомполагаться：

dependencies {
    // Прямая зависимостьидентификацияизJARдокумент    implementation files('libs/foo.jar', 'libs/bar.jar')

    // Конфигурация папки как элемента дляполагаться, автоматически включает все файлы JAR в папку.
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

делатьиспользоватьfileTreeметодчас,Gradle автоматически включит все файлы JAR в указанный каталог как можнополагаться.

Подвести итог

• Прямая зависимость：Получить с удаленного складаизполагаться,Оператор координат Makeuse.
• Зависимости проекта：существовать Многомодульный проектсередина,Один модуль к другому модулю изполагаться.
• Локальные зависимости JAR：Прямая цитатаиспользоватьместныйдокументсистемасерединаизJARдокумент。

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

2. Зависимые загрузки

Когда команда сборки будет выполнена, gradle загрузит соответствующий Jar из настроенного хранилища зависимостей и применит его к проекту.

3. Тип зависимости

Подобно тегу области Maven, gradle также предоставляет типы зависимостей, как показано ниже:

пожалуйста, обрати внимание,compileиruntimeВарианты конфигурациисуществоватьGradle 7.0серединабыл удален,рекомендоватьделатьиспользоватьimplementationиruntimeOnlyделатьдлязаменять。также,apiиcompileOnlyApiдаjava-libraryплагинпоставлятьиз,use используется для более детального управления отношениями между модулями.

Официальная ссылка на документ： https://docs.gradle.org/current/userguide/java_library_plugin.html#java_library_plugin: Отношения и описания каждой области зависимостей https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal : Обновление и удаление области зависимостей https://docs.gradle.org/current/userguide/java_library_plugin.html#java_library_plugin：API и implemention разница https://docs.gradle.org/current/userguide/java_plugin.html#java_plugin: осуществлять java Какие зависимости используются в команде.

намекать：java Функции, предоставляемые плагинами, java-библиотекой Плагины предоставляются

4. Разница между API и реализацией

Вот что вы можете предложить о Gradle конфигурацииapiиimplementationизсравнительная таблица,Я оптимизировал и систематизировал это:

apiиimplementationдаGradleсерединачастоиспользоватьиз Два видаполагаться Варианты конфигурации,онисуществоватьвремя компиляцииивремя выполненияиз ХОРОШОдлядругой。apiВарианты конфигурациипозволятьполагатьсяпередача,Этот существующий мультимодуль из проекта очень полезен.,Можно гарантировать, что модульизполагатьсяреляционная согласованность。иimplementationВарианты конфигурациине будетполагатьсяпередача Даватьделатьиспользовать ВОЗ,Такое существование в большинстве случаев рекомендуется использоватьиз,Потому что для этого можно сократить ненужные изполагаться при прохождении,Тем самым повышая эффективность строительства объекта.

Ниже приводится подробное объяснение двух типов опор и их различных эффектов:

4.1 Зависимости API

• время компиляции：Когда библиотека（нравиться libC) объявлен для api опираться, когда изменения в содержании вызовут все прямые и косвенные предположения, которые он проектирует. (например, libA и projectX) необходимо переустановить. Это потому, что для api Изменения в опоре могут затронуть всех пользователей использования. API код.
• время выполнения：существоватьвремя выполнение, все прошло api Зависимые библиотеки (например, libC, libA) и, в конечном итоге, программа (например, ProjectX) будут загружены загрузчиком классов.
• подходящийиспользоватьсцена：api Он подходит для управления многомодульными проектами, особенно если вы хотите избежать дублирования. Например, если moduleA полагаться модуль B,в то время как moduleB сноваполагаться модуль C, в то же время moduleA Также необходимо moduleC В некоторых методах класса вы можете moduleC делатьдля api полагатьсядобавить в moduleB середина. Таким образом,модуль A Просто нужнополагаться модуль B, в то время как moduleC изполагаться будет передано.

4.2 зависимости реализации

• время компиляции：делатьиспользовать implementation Когда опорся, опора из транзитивности ограничена. Если библиотека, такая как libD) объявлен для implementation Опирается, и это из содержания меняется, только Прямая зависимостьэтоиз Библиотека（нравиться libB）Нужно повторнокомпилировать。Нетполагаться В libD проекты (например, libA и projectX) не нужно переустанавливать, что может ускорить процесс.
• время выполнения：хотясуществоватьвремя компиляции implementation полагаться Нетбудетпередача,носуществоватьвремя выполнение, все прошло implementation опорся вводит из библиотек (таких как libD, libB) и, в конечном итоге, программа (например, Все классы в projectX) будут загружены.
• подходящийиспользоватьсцена：implementation use подходит для программ, которые не должны использоваться другими модулями напрямую с использованием библиотеки useiz. Обычно это внутренняя деталь реализации, не раскрываемая общественности. API из.

4.3 расширять

api и implementation Тематическое исследование :

В многомодульном проекте используйте api и implementation Зависимостями между модулями можно эффективно управлять:

• делатьиспользовать api：Если вам нужен модульизполагатьсястановитьсядлядругой модульизобщественный API час,делатьиспользовать api。так,Любой опирающийся проект с этим модулем может получить доступ к этим API.
• делатьиспользовать implementation：Если вы хотите скрыть модульиз Детали реализации,Когда только необходимая функциональность подвергается воздействию других модулей,делатьиспользовать implementation。это помогает Вуменьшатьвремя компиляциязполагаться передаче для повышения эффективности сборки.

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

5. Конфликты зависимостей и их решения

Конфликт зависимостей означает, что «в процессе компиляции, если существует несколько версий определенной зависимости, система сборки должна выбрать, какую из них собирать», как показано ниже:

image-20240420195402674

A, B и C — это локальные модули подпроекта, а log4j — удаленная зависимость.

время компиляции： B использовать 1.4.2 версия log4j,C использовать 2.2.4 версия log4j,B и C никакого конфликта между

При упаковке: Может быть только один код версии, который в конечном итоге будет упакован в окончательную версию, соответствующую jar или военный пакет, для Gradle Здесь конфликт

5.1 Демонстрация случая:

Вводим зависимые библиотеки в build.gradle

image-20240420195849916

Изменить build.gradle

image-20240420195949082

Как показано выше: по умолчанию Gradle встречаделатьиспользоватьдо настоящего времениверсия jar Пакет【учитывать новую версию jar Пакеты, как правило, обратно совместимы].

дапредположениеделатьиспользовать Официально привезеноизэто решение。Конечно, помимо этого, Gradle также предоставляет ряд методов для разрешения конфликтов зависимости от: exclude

Удаление зависимости,Транзитивные зависимости не допускаются.,Принудительно использовать определенную версию。

5.2 Исключить исключает зависимость

image-20240420200138605

5.3 Передача зависимостей не разрешена [обычно не используется]

image-20240420200227442

При добавлении зависимостей, если вы установите transitive для false, означает отключение поддержки доставки. т.е. все предположения внутри из не будут добавлены в компилироватьвремя выполнение classpath.

5.4 Принудительное использование определенной версии [Официальная рекомендация]

image-20240420200349538

расширять

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

Вот пример того, как настроить Gradle на немедленный сбой при возникновении конфликта зависимостей:

configurations.all {
    resolutionStrategy.failOnVersionConflict()
}

Этот код должен быть размещен в вашем build.gradle изпроекта Конфигурация части файла. Делаяиспользовать configurations.all метод,ты можешьдляпроектсерединавсеиз Конфигурацияотвечатьиспользоватьэта стратегия。resolutionStrategy.failOnVersionConflict() позволит Gradle Если при разрешении зависимостей возникают какие-либо конфликты версий, сборка будет немедленно остановлена ​​и будет выдано сообщение об ошибке.

Преимущества проверки конфликта зависимостей

• Оперативно находите проблемы：Сборка не удаласьпоставлятьясныйиз Сигнал,Указывает на то, что существуют несовместимые версии между опорся и существованием.,Это предотвращает случайное включение несовместимых изполаганий в сборку.
• Упрощение отладки：Это нормально – потерпеть неудачу сразу Упрощение процесс отладки, потому что вам не нужно гадать, что построить успешно, но время выполнение, но есть проблема.
• избегатьвремя выполненияошибка：обеспечивая всеполагаться Вседасовместимыйиз,можно уменьшитьвремя выполнение Непредвиденная ошибка из-за несоответствия опор.

На что следует обратить внимание

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

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