#java #gradle #build.gradle
#java #gradle #build.gradle
Вопрос:
Я использую repositories{} block для объявления репозиториев для разрешения зависимостей в файле build.gradle. Есть ли какой-либо способ объявить репозитории вне файла build.gradle, чтобы мне не приходилось объявлять для любых других проектов.
Я исхожу из фона maven, где мы могли бы объявлять репозитории в settings.xml в папке .m2.
Пожалуйста, посоветуйте.
Комментарии:
1. Я понял это позже. Ответом на это является объявление сведений о репозитории в файле gradle.properties как глобальной переменной в вашей папке .gradle в каталоге пользователя. Вы можете использовать эти глобальные переменные в своем build.gradle для всех локальных проектов.
Ответ №1:
Источник ваших зависимостей является важной частью вашей сборки. Это один из многих элементов, которые помогают обеспечить воспроизводимые сборки. Maven предполагает, что данная версия зависимости одинакова во всех репозиториях. К сожалению, это не так.
Поэтому естественно объявлять репозитории в каждой сборке Gradle. Это может быть реализовано извне, если объявления поступают из внешнего скрипта, который применяется в вашем проекте.
И этот скрипт должен полагаться на allprojects блок, чтобы убедиться, что репозитории добавлены ко всем проектам сборки нескольких проектов.
Комментарии:
1. Я считаю, что все еще должен быть способ предоставления репозиториев вне build.gradle в local, учитывая, что обычно в организации у нас обычно очень стандартная структура репозиториев для разрешения зависимостей, и объявление этих репозиториев в каждом файле build.gradle не имеет смысла. это своего рода создание жестких зависимостей для каждого проекта. Кроме того, при перемещении в область разработки Дженкинс может позаботиться о разрешении зависимостей в конфигурации задания сборки, которая снова находится за пределами build.gradle.
2. Я не уверен, что жестко запрограммированный репозиторий в репозитории кода также является хорошей идеей. Это может вызвать проблемы, когда репозитории недоступны или вообще исчезают (например, Codehaus). Возможность указать репозиторий внутри организации на самом деле также хороша для воспроизводимости: вы не так сильно зависите от внешних факторов, когда библиотека кэшируется. (Кроме того, Maven / Gradle, похоже, имеют тенденцию «пропускать» имена библиотек, которые вы пытаетесь загрузить, даже внутренние имена, что может быть проблемой.) По крайней мере, возможность переопределения с помощью локальной конфигурации была бы хорошей.