Что такое Maven Snapshot и для чего он нужен?
В мире разработки программного обеспечения часто возникает ситуация, когда над одним проектом работает несколько команд разработчиков. В таких случаях, когда каждая команда разрабатывает свой модуль, возникает необходимость в обмене промежуточными версиями модулей для тестирования или интеграции. В этом и заключается основная идея Maven Snapshot.
Maven Snapshot — это специальная версия артефакта, которая позволяет разработчикам обмениваться промежуточными версиями проекта. Основное отличие Snapshot версии от обычной заключается в том, что они динамичны, то есть при каждом обновлении проекта, Maven автоматически обновляет Snapshot версию.
Примером может служить следующая ситуация. Представим, что есть две команды разработчиков, каждая из которых работает над своим модулем проекта. Команда A выполнила определенный набор изменений в своем модуле и хочет, чтобы команда B протестировала их. Для этого команда A создает Snapshot своего модуля и делает его доступным для команды B. Команда B, в свою очередь, может использовать этот Snapshot для тестирования или интеграции с их собственным модулем.
Таким образом, Maven Snapshot позволяет командам разработчиков обмениваться промежуточными версиями модулей, что упрощает процесс тестирования и интеграции. Это особенно полезно в больших проектах, где над одним проектом работают несколько команд разработчиков.
Maven – Снимки
Большое программное приложение обычно состоит из нескольких модулей, и это обычный сценарий, когда несколько команд работают над разными модулями одного и того же приложения. Например, рассмотрим команду, работающую над внешним интерфейсом приложения как проект app-ui (app-ui.jar: 1.0), и они используют проект службы данных (data-service.jar: 1.0).
Теперь может случиться так, что команда, работающая над сервисом данных, быстро исправляет ошибки или совершенствуется, и они выпускают библиотеку в удаленное хранилище почти каждый день.
Теперь, если команда службы обработки данных загружает новую версию через день, возникают следующие проблемы:
- Команда службы данных должна сообщать команде app-ui каждый раз, когда они выпускают обновленный код.
- Команда app-ui должна регулярно обновлять свой pom.xml, чтобы получить обновленную версию.
Команда службы данных должна сообщать команде app-ui каждый раз, когда они выпускают обновленный код.
Команда app-ui должна регулярно обновлять свой pom.xml, чтобы получить обновленную версию.
Чтобы справиться с такой ситуацией, в игру вступает концепция SNAPSHOT .
Что такое SNAPSHOT?
SNAPSHOT – это специальная версия, которая указывает текущую версию разработки. В отличие от обычных версий, Maven проверяет наличие новой версии SNAPSHOT в удаленном репозитории для каждой сборки.
Теперь команда по обслуживанию данных будет каждый раз выпускать обновленный код SNAPSHOT в хранилище, скажем, data-service: 1.0-SNAPSHOT, заменяя более старую банку SNAPSHOT.
Снимок против версии
В случае Версии, если Maven однажды скачал упомянутую версию, скажем, data-service: 1.0, он никогда не будет пытаться загрузить более новую версию 1.0, доступную в репозитории. Для загрузки обновленного кода необходимо обновить версию службы данных до версии 1.1.
В случае SNAPSHOT Maven будет автоматически загружать последнюю версию SNAPSHOT (data-service: 1.0-SNAPSHOT) каждый раз, когда команда app-ui создает свой проект.
app-ui pom.xml
Проект app-ui использует 1.0-SNAPSHOT службы данных.
xmlns = "http://maven.apache.org/POM/4.0.0" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 4.0.0 app-ui app-ui 1.0 jar health http://maven.apache.org UTF-8 data-service data-service 1.0-SNAPSHOT test
служба данных pom.xml
Проект data-service выпускает 1.0-SNAPSHOT для каждого незначительного изменения.
4.0.0 data-service data-service 1.0-SNAPSHOT jar health http://maven.apache.org UTF-8
Хотя в случае SNAPSHOT Maven автоматически выбирает последнюю версию SNAPSHOT ежедневно, вы можете заставить maven загрузить последнюю сборку моментального снимка, используя ключ -U для любой команды maven.
mvn clean package -U
Давайте откроем командную консоль, перейдем в каталог C: \> MVN> app-ui и выполним следующую команду mvn .
C:\MVN\app-ui>mvn clean package -U
Maven начнет сборку проекта после загрузки последней версии SNAPSHOT data-service.
Автоматизация рутины при выпуске релизов с Maven
Выпуск релиза для многомодульного проекта дело не простое. Как автоматизировать процесс и версиях модулей?
31 дек. 2022 · 4 минуты на чтение
Думаю вам знакома боль выпуска релиза, если архитектура вашего приложения это большой многомодульный монолит, или если вы пишите большую библиотеку.
Проблема в том, что при релизе вам необходимо изменить версию в pom.xml каждого модуля. И если делать это руками довольно утомительно, и высока вероятность совершить ошибку.
Для облегчения релизов воспользуйтесь плагином maven-release-plugin . Разберемся, что он умеет и чем полезен.
Спонсор поста
Для начала просто добавим плагин в проект, и посмотрим на его работу с настройками по умолчанию.
Плагин покрывает все операции, которые необходимо проделать перед релизом. Он может:
- Изменить версию каждого модуля отдельно или все разом.
- Прописать новый SNAPSHOT тег.
- Закоммитеть эти изменения и/или запушить их.
- Поставить релиз-тег или создать релиз ветку.
- Активировать нужные maven профили.
- Выполнить нужные maven стадии.
Все это можно выполнить либо в интерактивном режиме, либо применять значения по умолчанию, либо передавать параметрами при запуске. Последние 2 режима отлично подойдут для CI/CD.
А вот команда, которая делает большую часть работы:
mvn release:prepareЭта стадия, позволяет убедиться, что приложение готово к релизу, например, не содержит snapshot зависимости. Она включает в себя множество действий:
- Проверка наличия не зафиксированных изменений в git.
- Проверка наличия snapshot зависимостей.
- Изменение snapshot версий ваших модулей на релизные.
- Запуск maven стадий. По умолчанию это clean verify .
- Создание коммита.
- Пуш в удаленный репозиторий.
- Изменение релизной версии ваших модулей на новый snapshot
Во время работы плагина для каждого модуля необходимо указать новую версию, потом указать название для релиз-тега, а после указать новые snapshot зависимости.
Все возможности плагина отлично описаны в официальной документации. В этой статье я рассмотрю только некоторые варианты использования.
Одна версия для всех модулей
Если подмодули вашего приложения всегда получают ту же версию, что и родителський pom, имеет смысл указать в конфигурации плагина:
org.apache.maven.plugins maven-release-plugin $ true Тогда ввести нужно будет значение только для родительского pom, а все подмодули и подмодули их подмодулей получат то же значение.
Отмена push
Push в репозиторий будет выполняться по тем данным, что есть в pom в разделе scm .
Резюмирую
Рассмотренный плагин maven-release-plugin значительно упрощает процедеру релиза для многомодульных проектов, что экономит время и позволяет избежать ошибок в версионировании проекта.
Maven snapshot что это
Apache Maven (Часть 1): Основы
Apache Maven
(Часть 1): Основы
Apache Maven (обычно называют просто Maven) — это фреймворк по автоматизации и управлению сборкой Java-приложений. Слово Maven взято из языка идиш, примерный перевод которого можно выразить как «собиратель знания» (accumulator of knowledge), «эксперт».
Apache Maven, по большей части, написан на Java. Это проект с открытым исходным кодом, который следует философии «Соглашение важнее конфигурации» (convention over configuration).
1. Основные возможности Maven
Наиболее важные возможности Maven:
- Простая настройка проекта в соответствии с лучшими практиками
- Управление зависимостями, включая автоматическое обновление
- Возможность работать с несколькими проектами одновременно
- Большое хранилище библиотек и метаданных для использования «из коробки»
- Расширяемость с возможностью написания своих плагинов
- Создание сайта и PDF с документацией
- Проверка корректности структуры проекта
- Компиляция исходного кода, отображение ошибок/предупреждений
- Тестирование проекта на основе уже написанных тестов
- Упаковка скомпилированного кода в артефакты (например, .jar, .war, .ear, .zip-архивы и многое другое)
- Упаковка исходного кода в загружаемые архивы/артефакты
- Установка упакованных артефактов на сервер для последующего развертывания (деплоя) или в репозиторий для распространения
- Создание отчетов по тестированию
- Сообщение об удачной/неудачной сборке проекта
2. Принцип «Соглашение важнее конфигурации»
Соглашение важнее конфигурации — это принцип проектирования программного обеспечения, целью которого является уменьшение количества лишних действий, необходимых разработчику при создании своего проекта.
В Apache Maven данный принцип проявляется в том, что Maven предоставляет разумные настройки (готовые шаблоны) по умолчанию для управления сборкой проекта. Если они не подходят, то разработчик может переопределить их на свои.
Одной из таких настроек по умолчанию, например, является структура каталогов в Maven-проекте (подробнее о стандартных каталогах):
В этой структуре исходный код, в соответствии с соглашением, располагается в подкаталоге src/main/java. В каталоге test находится код тестов.
Аналогичным образом ресурсы, необходимые для приложения или его тестирования, находятся в каталоге resources.
Это всего лишь один из множества примеров стандартизации в соответствии с философией «Соглашение важнее конфигурации».
3. Как работает Maven?
Maven использует объектную модель проекта (Project Object Model, POM) для управления проектом. Для описания модели обычно используется XML-документ, но возможны и другие форматы.
Рисунок, иллюстрирующий типичную работу Maven
4. Что такое Объектная модель проекта (POM)?
POM — это очень полезная и удобная вещь, которая описывает то, как будет собираться проект. Этот файл (обычно pom.xml) состоит из следующих частей:
- Project coordinates (координаты проекта) — однозначно идентифицируемый набор свойств, с помощью которых артефакты проекта могут быть использованы в другом месте
- Dependencies (зависимости) — библиотеки и код, необходимые для сборки проекта
- Plugins (плагины) — вспомогательные инструменты при сборке проекта
- Properties (свойства) — общие значения, необходимые проекту
- Inheritance details (детали наследования) — возможность создания иерархии для повторно используемых компонентов POM
- Profiles (профили) — альтернативные пути сборки проекта, разбитые по профилям
4.1. Как Maven взаимодействует с POM?
Maven использует содержимое в POM для управления сборкой. Однако он также имеет стандартные значения по умолчанию. Таким образом, Maven несет ответственность за объединение значений по умолчанию и применение переопределений и дополнений, обнаруженных в pom-файле проекта.
Благодаря этому мы получаем:
- совокупность шагов выполнения, свойств и профилей
- контент, который Maven может выполнить для проекта
- исчерпывающий набор зависимостей и плагинов, необходимых для такого выполнения
- определение любых переходных зависимостей (например, зависимости зависимостей)
- разрешение конфликтов с точки зрения версий зависимостей
4.2. Как Maven собирает POM?
Maven собирает свой POM, проходя слои, которые действуют как строительные блоки. Каждый используемый слой имеет возможность переопределять или дополнять содержимое того, что станет POM. Родительские файлы, спецификации и файлы POM-проекта — это то, где можно переопределить настройки Maven по умолчанию.
Теперь пройдемся по существующим слоям:
Внутренние настройки Maven
Этот слой находится в коде Maven. Если не предполагается править его исходник, то эти значения по умолчанию можно считать неизменяемыми.
Maven Super POM
Этот супер-POM также является частью кода Maven. Опять же, если цель не состоит в том, чтобы изменить исходник, то также можно считать, что Super POM является неизменяемым.
Глобальные настройки Maven
После установки Maven создает структуру каталогов. Одним из базовых каталогов является conf, содержащий файл глобальных настроек settings.xml. Поскольку этот файл существует на локальном компьютере, он доступен для редактирования. Как правило, любые параметры, которые применяются ко всем проектам, управляемым на конкретном компьютере, прописываются в этом глобальном settings.xml. Например, в этот файл входят такие параметры, как настройки прокси-сервера, URL-адреса корпоративных серверов, зеркала и т. д. В любом случае его не следует часто изменять.
Расположение:
Unix/MacOS: /conf/settings.xml
Windows:
Пользовательские настройки Maven
Аналогично глобальным настройкам, но в другом месте, можно создать файл пользовательских настроек. Этот файл также называется settings.xml, но его местоположение находится в папке пользователя (user home) в каталоге .m2 (скрытая папка). Данный файл предназначен для настройки любых параметров, применимых к проектам. Управляется конкретным пользователем (на данном компьютере может быть несколько пользователей). Это могут быть имена пользователей и пароли для подключения к сети, параметры репозитория и т. д.
Расположение:
Unix/MacOS: /.m2/settings.xml
Windows: \.m2\settings.xml
Родительские POM’ы / спецификации
Maven позволяет наследовать содержимое от родительского POM и характеристики версий из pom-спецификации. Обычно родительские POM содержат повторно используемые зависимости, плагины и свойства, используемые POM проекта. POM-спецификации (Bill-of-Material — BOM) — это специализированный POM, который позволяет группировать версии зависимостей. Использование POM-спецификации избавляет разработчика от необходимости проверять совместимость различных зависимостей. Изменение любого из них возможно, если есть необходимость и право на изменение. Поскольку изменения в любом из них могут повлиять на несколько других проектов, для изменений рекомендуется соответствующее увеличение версий и их пересмотр.
Расположение:
Различные места на компьютере или в каком-либо репозитории.
Project POM
Это Project Object Model для проекта. В этом месте подробно описаны инструкции Maven для конкретного проекта. Типичное содержимое включает в себя: уникальный набор координат, используемых для идентификации проекта; название и описание проекта; набор разработчиков, связанных с проектом; любые сведения об управлении системой контроля версиями; все зависимости и плагины для конкретного проекта; любые профили, которые позволяют поочередно выполнять Maven в этом проекте и так далее. Все это будет описано в последующих статьях. Файл, содержащий этот POM, называется pom.xml, но можно использовать и другие имена. Если используется альтернативное имя, то исполняемому файлу Maven необходимо будет указать имя файла для выполнения.
Расположение:
Unix/MacOS: $PROJECT/pom.xml
Windows: $PROJECT\pom.xml
6. Координаты зависимостей
Существуют сотни или тысячи проектов, которые собраны в артефакты. Некоторые из этих артефактов потенциально могут быть использованы в текущем проекте в качестве библиотек. Например, проект может зависеть от логирования или библиотеки JSON. В центральном репозитории можно разместить множество артефактов зависимостей. Основное такое хранилище Maven называется Maven Central. Существует также множество других подобных хранилищ.
Следующий вопрос заключается в том, как определить и загрузить точные артефакты, необходимые для проекта? Правильный способ идентифицировать артефакт — это использовать его координаты Maven.
Что такое координаты Maven?
Это способ уникальной идентификации артефакта. Существуют три основные координаты, которые используются для идентификации артефакта.
groupId
Классификация по группе, обычно относящаяся к организации или компании и может иметь общее название для одного или нескольких проектов. groupId обычно описан через точку (аналогично имени пакета Java). Каждый элемент в этой точечной нотации соответствует каталогу в древовидной структуре хранилища. Например, groupId в org.apache.commons соответствует $REPO/org/apache/commons.
Наличие точечной нотации не является обязательным требованием (хотя очень рекомендуется).
artifactId
Это точное название проекта. Среди множества проектов, существующих в группе, artifactId может однозначно идентифицировать артефакт. Если название состоит из нескольких слов, то в описании artifactId оно разделяется дефисами. В идеале, имена должны быть небольшой длины.
Артефакт проявляется в виде подкаталога в дереве каталогов, представленного groupId. Например, artifactId commons-lang3 в groupId org.apache.commons сообщает, что артефакт можно найти в разделе: $REPO/org/apache/commons/commons-lang3/.
version
Это идентификатор, который отслеживает уникальные сборки артефакта. Версия — это строка, созданная разработчиками проекта для определения набора изменений, внесенных в предыдущее создание артефакта того же проекта. Настоятельно рекомендуется следовать схемам семантического управления версиями, хотя это не обязательно.
Версия проявляется в виде подкаталога в дереве каталогов, который состоит из groupId и artifactId. Например, version 3.1.0 для artifactId commons-lang3 в groupId org.apache.commons обозначает, что артефакт находится в $REPO/org/apache/commons/commons-lang3/3.1.0/.
Теперь немного подробнее про версии.
Схемы номеров версий
Следуя стандартным жизненным циклам разработки программного обеспечения (ПО), проект может проходить этапы разработки, каждый из которых состоит из нескольких попыток создания ПО: тестирование, исправление ошибок, внесение дальнейших необходимых изменений и т. д. Как только цикл завершается, продукт помечается для релиза (выпуска). Эти жизненные циклы и фазы не имеют ничего общего с Maven.
Цикл разработки
Во время разработки продукта может быть создано несколько артефактов, которые можно протестировать, проверить и т. д. Этот цикл разработки обычно создает артефакты с той же версией, что и предыдущие сборки на том же этапе. Основанием для этого утверждения является то, что релиз все еще находится в экспериментальном, бета- или альфа-состоянии, но может претерпеть дополнительные изменения. Однако трудно заставить все проекты постоянно обновлять свои собственные POM для каждой такой сборки. В этой проблеме помогает создание SNAPSHOT’ов (снимков).
Например, для проекта A версии 1.0.0 команда разработчиков может создать несколько версий SNAPSHOT’ов с версией 1.0.0-SNAPSHOT в течение определенного периода времени. Этот суффикс подразумевает, что номер версии в конце должен быть 1.0.0, однако при каждой сборке будут создаваться новые артефакты, которые заменят предыдущий SNAPSHOT. Более новый SNAPSHOT может заменить существующий SNAPSHOT артефакта в репозитории Maven, поэтому пользовательские проекты могут безопасно получить последнюю версию SNAPSHOT’а. SNAPSHOT — это изменяемая версия проекта, которая может быть объявлена как зависимость в пользовательских проектах.
Готово для выпуска в продакшн (Production-Ready)
После завершения всего тестирования POM больше не нуждается в суффиксе SNAPSHOT и может создать готовую к продакшену неизменяемую версию проекта. Как только она будет помещена в репозиторий, в нее нельзя вносить никаких дальнейших изменений (Maven не позволяет это делать по своим внутренним правилам). Обычно можно найти другие готовые к производству суффиксы: 1.0.0-GA (общая доступность) или 1.0.0-RELEASE (выпущенный артефакт) или 1.0.0-FINAL и т. д. Опять же, строки версий вообще не имеют значения для Maven.