Как Maven ищет артефакты при сборке приложения

Что проверяют

Понимаете ли вы, откуда берётся каждая зависимость в сборке и почему на двух машинах сборка может вести себя по-разному. Следом почти всегда спрашивают про конфликт версий и про то, зачем компании свой Nexus или Artifactory.

Как отвечать

Цепочка поиска выглядит так:

• локальный репозиторий: по умолчанию ~/.m2/repository, путь меняется через <localRepository> в settings.xml или -Dmaven.repo.local. Если артефакт там есть, в сеть Maven не идёт;
• удалённые репозитории: Maven перебирает их по порядку, сначала из активных профилей settings.xml, затем из pom.xml проекта и родительских POM, в конце central из Super POM;
• зеркала: <mirror> в settings.xml перехватывает запросы. В компаниях обычно стоит <mirrorOf>*</mirrorOf>, и всё идёт через внутренний Nexus. С Maven 3.8.1 репозитории по голому HTTP заблокированы по умолчанию;
• кэш: скачанный артефакт ложится в локальный репозиторий. Релиз считается неизменным и повторно не скачивается, SNAPSHOT проверяется по updatePolicy, по умолчанию раз в сутки. -U форсирует проверку, -o включает офлайн;
• плагины: ищутся отдельно, в <pluginRepositories>.

Конфликт версий Maven решает правилом «ближайший побеждает»: берётся версия с наименьшей глубиной в дереве зависимостей, при равной глубине та, что объявлена раньше. Управлять этим стоит через <dependencyManagement> или импорт BOM, а смотреть дерево через mvn dependency:tree.

Где спотыкаются

Говорят, что Maven при каждой сборке перепроверяет все артефакты. Это касается только SNAPSHOT, релиз скачивается один раз.

Путают разрешение конфликтов с выбором самой новой версии. Maven не сравнивает номера, он смотрит на глубину, поэтому старая транзитивная версия спокойно побеждает новую.

Не знают про файлы .lastUpdated: неудачная попытка скачать тоже кэшируется, и до истечения интервала обновления Maven не пробует снова. Лечится флагом -U или удалением каталога артефакта.