Моя команда переносит наш код в среду Azure, и собственная статья Microsoft по этому вопросу описывает, как использовать Maven в среде Azure: https://docs.microsoft.com/en-us/azure/devops/java/labs/mavenpmvsts/?view=vsts
Одна из лучших рекомендаций Maven - избегать определения элементов репозитория.в файле pom и используйте вместо этого менеджер репозитория, настроенный в файле settings.xml.
В статье Microsoft указано иное: они говорят, что нужно добавить URL-адрес хранилища прямо в файл pom.
Я бывсе было в порядке, если элемент хранилища был определен только в разделе distributionManagement, но это не так.Статья определяет URL-адрес в элементе репозитория вне контекста распространения.
Насколько я понимаю, элемент репозитория файла pom.xml переопределяет источник артефактов, используемых для извлечения зависимостей.Проблема, которую я вижу, определяя это в файле pom, заключается в том, что это может иметь неблагоприятные последствия в зависимости от повторного использования библиотеки.
Пример использования: 1) Общая библиотека создается с URL-адресом хранилища, определенным в pom 2) ОбщийБиблиотека развернута.POM-файл, содержащий URL и JAR-файл, публикуется.3) Репозиторий артефактов перемещен, переименован или скопирован, URL-адрес изменен.4) Позже, новое приложение, использующее эту общую библиотеку, создается, но использует новый URL-адрес хранилища.URL-адрес в pom приложения теперь отличается от URL-адреса ранее опубликованного pom общей библиотеки.
Поскольку Maven использует граф зависимостей и наследование, я ожидаю, что при создании нового приложения:
1) maven прочитает файл pom приложения и начнет исследовать граф зависимостей, загрузив файлы pom для каждой зависимости приложения с URL-адреса, найденного в pom приложения.В этом случае единственной загрузкой является pom общей библиотеки.
2) maven исследует переходные зависимости и считывает pom общей библиотеки.При чтении pom общей библиотеки раздел репозитория будет иметь приоритет над pom приложения в контексте зависимостей общей библиотеки.Poms зависимостей в общей библиотеке будут загружаться со старого URL.
3) maven будет продолжать таким же образом и загружать все файлы pom, пока не будет построено дерево зависимостей.
4) в зависимости отПри настройке проекта maven просматривает построенный граф для загрузки jar-файлов и т. д., используя те же правила.
В этом случае maven будет загружать артефакты как из старого, так и из нового источника.Если старый источник больше не существует или недоступен в этом контексте сборки, проект не может быть собран.Вот почему лучше избегать установки URL репозитория в pom-файле.
Или так я думал.
Я написал сценарий демонстрации с локальными репозиториями, чтобы точно показать моей команде, что произойдет, иК моему удивлению, даже несмотря на то, что Maven действительно загружает pom-файл общей библиотеки, содержащий другой URL-адрес хранилища, тег хранилища, похоже, не перекрывает тег из создаваемого приложения.Журналы показывают все артефакты, загружаемые из источника, указанного в «верхнем» приложении.
Поэтому мой вопрос к переполнению стека состоит из двух частей:
1) Почему я не прав?Неужели я неправильно понял наследование, построение и поведение графа зависимостей в Maven?
2) Разве Maven не должен загружать зависимости общей библиотеки по URL-адресу, указанному в теге репозитория, если он указан?Я уверен, что в некоторых случаях артефакты должны поступать из частного репо.(например: org.geotools)
3) У кого-нибудь есть опыт настройки Maven в Azure?Следовали ли вы руководству Microsoft или нашли способ переместить URL-адреса хранилища в файл settings.xml в среде Azure?