Этап 9 - Repository: хранение и распространение артефактов
Зависимость должна откуда-то скачиваться, а собственную библиотеку нужно куда-то публиковать, если она нужна другому проекту. Artifact репозитории решают эту задачу распространения.
Репозиторий - это хранилище артефактов сборки и метаданных. Maven, Gradle и другие инструменты используют репозитории, чтобы скачивать зависимости и загружать артефакты.
Какую проблему это решает
Local Maven репозиторий обычно находится в ~/.m2/репозиторий. Это cache и локальный publishing target для mvn install. У Gradle есть свои caches, но он также умеет читать Maven-style репозитории.
Remote репозитории - это network locations. Maven Central - публичный репозиторий, который используют большинство Java проекты. Компания часто добавляет Nexus или Artifactory, чтобы proxy публичный зависимости и host приватный артефакты.
Nexus может работать как proxy, hosted или group репозиторий. Proxy кэширует артефакты из Maven Central. Hosted хранит company артефакты. Group дает разработчикам один URL, агрегирующий несколько репозитории.
Artifactory решает похожие задачи репозиторий management и часто поддерживает более широкий package ecosystem. Выбор зависит от infrastructure, permissions, metadata needs и package types.
Release артефакты - immutable версии вроде 1.2.0. Snapshot артефакты вроде 1.2.1-SNAPSHOT - изменяемые development сборкаs. Использовать snapshots в production сборкаs рискованно, потому что reproducibility страдает.
Последовательность шагов
- локальный репозиторий.
- удаленный репозиторий.
- proxy/hosted репозиторий.
- релиз/snapshot артефакты.
Эта последовательность - картинка в голове, с которой нужно читать файлы сборки. Названия в Maven и Gradle отличаются, но практический вопрос одинаковый: какой входные данные используется, какая задача запускается, какой результат получается и где этот результат хранится.
Конкретный пример
<repositories>
<repository>
<id>company-releases</id>
<url>https://nexus.example.com/репозиторий/maven-релизs</url>
</repository>
</repositories>
Полезная таблица
| Понятие | Значение |
|---|---|
| Local репозиторий | Cache на машине разработчик, обычно ~/.m2. |
| Maven Central | Public репозиторий для open-source Java артефакты. |
| Nexus proxy | Кэширует артефакты из upstream репозитории. |
| Nexus hosted | Хранит приватный company артефакты. |
| Artifactory | Repository manager с широкой package support. |
| Snapshot | Изменяемая development версия. |
Где это встречается в работе
Относись к репозитории как к части цепочка поставки. Clean сборка должен скачивать зависимости из известных репозитории и publish артефакты по понятным релиз или snapshot rules.
В командной разработке знание сборки - не необязательная теория. Оно влияет на локальный development, время CI, зависимость upgrades, стабильность релиз и debugging. Когда Spring сервис не стартует после изменения зависимость, CI скачивает другую библиотека версия или артефакт не получается deployed, ответ обычно находится в сборка настройка, зависимость graph, упаковка step или репозиторий setup.
Частые ошибки
- Копировать настройка, не понимая, на какой слой сборка она влияет.
- Считать локально успешный сборка доказательством, что CI и production delivery тоже сработают.
- Игнорировать зависимость trees, сгенерированный результат и репозиторий rules до момента failed релиз.
- Смешивать приложение запуск приложения настройка и сборка-time настройка.
Чеклист понимания
- Я могу объяснить главные terms этой статьи, не перечитывая сборка file вслух.
- Я могу нарисовать последовательность от исходный код до артефакт для этой темы.
- Я могу назвать command или file, который первым проверю при сборка problem.
Вопросы для самопроверки
- Какую проблему этот сборка concept решает в реальном Java или Spring проект?
- Какой file или command быстрее всего даст evidence, когда что-то ломается?
- Какая ошибка заставит сборка работать локально, но падать в CI или у другого разработчик?
Практика перед следующим уроком
Найдите локальный Maven или Gradle cache и отыщите одну скачанную библиотеку. Затем откройте build-файл и определите, из какого удаленного репозитория этот артефакт мог бы скачаться, если локальный cache был пустой.