Виды репозиториев Maven: локальный, Maven Central и корпоративный - Вопросы

Репозиторий Maven - хранилище артефактов с фиксированной структурой каталогов, из которого Maven берёт зависимости и плагины и в которое публикует результаты сборки. Артефакт - файл, который адресуется координатами Maven groupId:artifactId:version: jar, war, pom-файл, архив исходников или Javadoc.

Путь вычисляется из координат: точки в groupId превращаются в каталоги, затем идут каталоги artifactId и версии, имя файла - artifactId-version.расширение. Например, com.google.code.gson:gson:2.11.0 лежит по пути com/google/code/gson/gson/2.11.0/gson-2.11.0.jar - и в ~/.m2/repository, и на https://repo.maven.apache.org/maven2. Поэтому локальный, центральный и корпоративный репозитории устроены одинаково.

В каталоге версии обычно лежат:

• gson-2.11.0.jar - сам артефакт (для packaging war - .war);
• gson-2.11.0.pom - POM библиотеки, из него Maven узнаёт её транзитивные зависимости; у BOM и родительских POM есть только этот файл;
• -sources.jar и -javadoc.jar - исходники и документация, скачиваются, только если их запросила IDE или команда (mvn dependency:sources);
• *.sha1 - контрольные суммы для проверки целостности;
• _remote.repositories - служебный файл: из какого репозитория (по id) получен артефакт;
• maven-metadata-*.xml - метаданные: список версий, последняя сборка SNAPSHOT.

В Maven есть локальный репозиторий и удалённые. Локальный - кэш на диске, в нём Maven ищет артефакты в первую очередь. Удалённым считается любой другой: центральный Maven Central (подключён по умолчанию), корпоративный репозиторий компании (Nexus, Artifactory) и сторонние публичные (например, https://jitpack.io), которые используются, только если явно объявлены.

Локальный репозиторий по умолчанию - ~/.m2/repository в Linux и macOS, C:\Users\<имя>\.m2\repository в Windows. Он свой у каждого пользователя и общий для всех его проектов: скачанная однажды библиотека повторно не скачивается.

Артефакты попадают туда двумя путями: Maven скачивает их из удалённых репозиториев при сборке, а mvn install кладёт результат сборки вашего проекта вместе с его POM. Плагины Maven - тоже артефакты, поэтому первая сборка даже пустого проекта скачивает десятки файлов. Jar, которого нет ни в одном репозитории, добавляют командой mvn install:install-file -Dfile=... -DgroupId=... -DartifactId=... -Dversion=... -Dpackaging=jar.

Каталог можно удалить: Maven скачает нужное заново, но свои модули придётся снова установить через mvn install. Путь меняют постоянно элементом <localRepository> в settings.xml или на один запуск: mvn package -Dmaven.repo.local=/tmp/m2-clean. Пустой каталог помогает проверить, соберётся ли проект «с нуля», как на CI-сервере.

Maven Central - публичный репозиторий, который Maven использует по умолчанию. Он объявлен во встроенном Super POM под id central с адресом https://repo.maven.apache.org/maven2, SNAPSHOT-версии для него отключены (snapshots enabled=false); увидеть это объявление можно в выводе mvn help:effective-pom. Объявлять central в своём pom.xml не нужно. В Central опубликованы практически все Java-библиотеки с открытым исходным кодом, поэтому большинству проектов настраивать репозитории не приходится.

Положить туда артефакт напрямую нельзя: публикация идёт через Central Portal компании Sonatype. Проверяется не код, а формальные требования: право на namespace (groupId подтверждается доменом или аккаунтом, например io.github.username), архивы исходников и Javadoc, подписи PGP, метаданные POM (name, description, url, лицензия, разработчики, scm). Опубликованный релиз нельзя ни перезаписать, ни удалить - исправление выпускают новой версией. SNAPSHOT-версии в Central не публикуются.

Официальный поиск по Central - central.sonatype.com (старый адрес search.maven.org). mvnrepository.com - неофициальный каталог: на нём удобно искать библиотеки и копировать фрагмент <dependency>, но сам он артефакты не раздаёт, поэтому указывать его адрес в <repositories> бессмысленно.

Для каждой зависимости и плагина Maven сначала проверяет локальный репозиторий; если файл есть (и это не SNAPSHOT, которому пора проверить обновления), сеть не нужна. Иначе удалённые репозитории опрашиваются по очереди, пока один не вернёт артефакт:

1. репозитории из активных профилей settings.xml (глобального, затем пользовательского);
2. репозитории из pom.xml проекта, затем из родительских POM, последним - central из Super POM;
3. репозитории, объявленные в POM-файлах зависимостей.

Найденный файл сохраняется в локальный репозиторий. Если для репозитория настроено зеркало, запрос уходит на адрес зеркала. В логе Downloading from central: ... слово после from - id репозитория, откуда реально пришёл файл. Неудача тоже кэшируется (*.lastUpdated): до истечения интервала обновлений Maven за артефактом не идёт, перепроверку заставляет флаг -U.

Дополнительный репозиторий объявляют в <repositories>: уникальный id, url, элементы <releases> и <snapshots> с enabled и updatePolicy (always, daily по умолчанию, interval:N, never). Для плагинов - отдельная секция <pluginRepositories>. Это оправданно для открытого проекта, которому нужен сторонний публичный репозиторий: проект соберётся у любого. Внутри компании адрес корпоративного репозитория задают один раз зеркалом в settings.xml. Логины и пароли в pom.xml не пишут: файл попадает в Git. Каждый лишний репозиторий замедляет поиск отсутствующих артефактов.

settings.xml - файл настроек Maven на конкретной машине, а не в проекте: пользовательский ~/.m2/settings.xml и глобальный conf/settings.xml в каталоге установки Maven (при совпадении настроек побеждает пользовательский). Основные элементы:

• localRepository - путь к локальному репозиторию;
• mirrors/mirror - подменяет адрес одного или всех удалённых репозиториев;
• servers/server - логин и пароль (или токен) для репозитория или зеркала с тем же id;
• proxies/proxy - HTTP-прокси для выхода в интернет;
• profiles, activeProfiles - дополнительные репозитории и свойства для всех проектов;
• offline - постоянный офлайн-режим (аналог -o).

Значения mirrorOf: * - все репозитории; central - только Maven Central; external:* - все, кроме локальных адресов; список с исключениями, например *,!jitpack. Зеркало * перехватывает и репозитории из <repositories> проекта - в логе тогда стоит id зеркала.

Учётные данные Maven берёт из server, id которого совпадает с id зеркала или репозитория; при несовпадении сервер отвечает 401 Unauthorized. Пароль удобно брать из переменных окружения (${env.NEXUS_PASSWORD}) или зашифровать командой mvn --encrypt-password (нужен мастер-пароль в ~/.m2/settings-security.xml). Какие настройки реально применились, показывает mvn help:effective-settings.

Корпоративный репозиторий - удалённый репозиторий на сервере компании, который хранит её собственные артефакты и кэширует публичные. Самые распространённые решения - Sonatype Nexus Repository и JFrog Artifactory; Maven-репозитории дают также GitHub Packages и GitLab Package Registry. Внутри сервера настраивают три типа репозиториев (в Artifactory - local, remote, virtual):

• hosted - хранит артефакты команды, опубликованные через mvn deploy (maven-releases, maven-snapshots);
• proxy - кэширует удалённый репозиторий: первый запрос скачивает файл из Central, следующие обслуживает сервер компании;
• group - объединяет несколько репозиториев под одним адресом, именно его указывают в зеркале.

Он даёт обмен внутренними библиотеками, закрытость кода, скорость и независимость сборок от интернета, контроль над уязвимыми библиотеками и лицензиями. Для подключения достаточно mirror и server в settings.xml.

mvn install копирует артефакт с POM только в локальный ~/.m2/repository - его видят лишь проекты на этой машине. mvn deploy делает то же и дополнительно загружает артефакт в удалённый репозиторий из <distributionManagement>: <repository> для релизов и <snapshotRepository> для SNAPSHOT-версий (Maven выбирает по суффиксу версии); логин берётся из server с тем же id. Обычно deploy запускает CI-сервер после успешной сборки. SNAPSHOT в удалённом репозитории хранится с меткой времени (shop-1.0-20261107.101530-1.jar), а релиз в hosted-репозитории по умолчанию перезаписать нельзя. Сторонний jar публикуют командой mvn deploy:deploy-file с параметрами -Durl и -DrepositoryId.