Maven, где мои артефакты? Еще одна статья про управление зависимостями
Легко жить с maven, когда есть доступ к центральному репозиторию, или у компании есть один корпоративный репозиторий. Все меняется, если работаешь в закрытом контуре, а количество репозиториев ближе к сотне. Под катом история о том, где искать потерявшийся артефакт и как для этого приготовить maven.
Что будет?
В статье будут примеры настройки settings, pom, описание поиска в репозиториях. Не будет настройки nexus\artifactory, проблем связанных с ними.
Начнем с простого
Добавим зависимость на spring в своем pom.
Если в локальном репозитории артефакта нет, то запрос пойдет в репозиторий central.
Мы не указывали этот репозиторий, но он всегда добавляется мавеном при сборке.
С такой конфигурацией порядок поиска будет аналогичен варианту с конфигурацией по умолчанию, но появится дополнительный шаг. Перед тем как пойти в central, мавен попытается скачать артефакт из репозитория nexus-corp.
Зеркало
Добавим зеркало для репозитория nexus-corp.
Когда maven дойдет до шага поиска в репозитории nexus-corp, то вместо него попытается найти артефакт в репозитории nexus-corp-mirror.
При этом если он не найдет его в nexus-corp-mirror, то запроса в nexus-corp не будет.
А если добавить зеркало с wildcard, то все запросы будут направлены на него, если не указаны другие зеркала.
Порядок поиска
В общем случае схема поиска будет такой:
1. Поиск в локальном репо
2. Поиск в репозиториях в порядке объявления с учетом приоритета (либо в их зеркалах)
В конце добавляется central. Он всегда последний, если не был перезаписан.
Merge конфигураций
Перед выполнением сборки maven «склеивает» конфиги:
The former settings.xml are also called global settings, the latter settings.xml are referred to as user settings. If both files exists, their contents gets merged, with the user-specific settings.xml being dominant.
По факту, если при склеивании не возникло конфликтов, то приоритет репозиториев следующий, в порядке уменьшения:
С разрешением конфликтов появилось еще большее непонимание. Если объявить репозиторий с одним id в разных профилях, то приоритет имеет глобальный конфиг, но если объявить профили с одинаковым id, то приоритет имеет пользовательский. Дальше экспериментировать уже не стал.
Поиск пропавших
1. Проверить правильность имени и версии артефакта.
2. Посмотреть какие репозитории\зеркала указаны в ваших settings\pom.
3. Проверить наличие артефакта в этих репозиторииях
Обычно проблема решается на втором шаге, но кроме этих пунктов встречаются проблемы из-за прокси, также бывает, что скаченный jar поврежден(хотя сам я сталкивался с таким всего один раз).
Для snapshot версий полезна команда -U — принудительное обновление snapshot зависимостей. По умолчанию maven обновляет их только после истечения таймаута раз в день(параметр updatePolicy)
Мы начнем с быстрого вступления, а затем перечислим преимущества его использования. После всего этого мы увидим процесс его установки, а затем несколько технических терминов, которые необходимы новичку. Итак, начнем!
Что такое Maven?
Maven позволяет разработчику автоматизировать обработку создания исходного формата папок, выполнения сортировки и тестирования, а также упаковки и развертывания окончательной сборки. Он сокращает значительное количество шагов в базовом процессе и делает процесс сборки простым.
Зачем используется Maven?
Подводя итог, Maven упрощает и стандартизирует процесс сборки проекта. Он легко выполняет групповую совместную работу, компиляцию, распространение, документирование и отдельные задачи. Maven увеличивает возможность многократного использования, а также выполняет большинство задач, связанных со сборкой.
Он работает на многих этапах, таких как добавление jar-файлов в библиотеку проекта, создание отчетов и выполнение тестовых примеров Junits, создание файлов Jar, War, Ear для проекта и многое другое.
Очень важным аспектом Maven является назначение хранилищ для управления файлами JAR.
Maven может также использоваться для создания и управления проектами, написанными на таких языках, как C #, ruby и других.
Давайте посмотрим на следующие преимущества Maven.
Настройка среды Maven
Установка Maven включает в себя следующие шаги:
Чтобы получить подробные инструкции по установке, следуйте приведенному ниже руководству на YouTube по настройке среды Maven, поскольку мы не хотим, чтобы эта статья была простой для чтения и скучной.
Данное руководство для начинающих, должно включать технические термины, связанные с MAVEN. Вот некоторые из них, которые очень важны:
Maven локальный репозиторий
Maven Центральный репозиторий
Центральный репозиторий Maven является местоположением по умолчанию для загрузки Maven всех библиотек зависимостей проекта для использования. Для любой библиотеки, участвующей в проекте, Maven сначала просматривает папку .m2 Локального репозитория, и если он не находит нужную библиотеку, он ищет в Центральном репозитории и загружает библиотеку в локальный репозиторий.
Maven POM
Элементы, используемые в создании файла pom.xml:
Зависимость (Dependency)
Плагин Surefire
Плагин Surefire необходим во время фазы тестирования жизненного цикла сборки для реализации модульных тестов приложения. Он создает отчеты в двух разных форматах, таких как обычный текстовый файл, XML-файлы, а также в HTML-файлах. Даже если вы используете инфраструктуру Junits или TestNG для создания отчетов, этот плагин необходим для использования, поскольку он помогает Maven находить тесты.
Практическое применение Maven
Когда вы работаете над конкретным проектом Java, и у этого проекта много зависимостей, сборок, требований, то работа со всеми этими вещами вручную является чрезвычайно сложной и трудоемкой. Таким образом, использование некоторых инструментов, которые могут выполнить эти работы, действительно полезно.
Идеальный мавен. Часть 1
Знаю, он не идеальный, но по крайней мере я попытаюсь рассказать, как его к этому приблизить.
В одну заметку всё не войдёт, поэтому сначала план:
Задача
Итак, начнем с постановки задачи. Предположим у нас есть группа людей (компания, фирма, кружок), которые разрабатывают проекты на Java. При этом у них есть как проекты с открытым кодом (OSS), так и проекты с закрытым кодом. Проекты, назовём их внутренние, разрабатываются независимо друг от друга, но между ними есть зависимости. Что хочется:
Важно понимать, что решать эти проблемы мы будем в комплексе, поэтому без реализации всех хотелок, система работать вообще не будет или будет, но не в полную силу.
Так же я хочу сказать, что все ниже написанное, это моё личное мнение, я осознаю, что мавен можно настроить по-разному, и я со своей стороны очень надеюсь найти нечто новое в обсуждении этой статьи, что поможет сделать существующую модель еще лучше. В свою защиту могу сказать, что модель, которую я буду описывать уже работает, и не один год. Открытая часть лежит на BitBucket, в частности, здесь.
Настраиваем мавен
Централизованное управление зависимостями на внешние библиотеки
Для управления сторонними зависимостями у мавена есть специальная секция dependencyManagement и механизм наследования. Казалась бы – вот и ответ, делаем «корпоративный» POM и наследуем от него корневые POM’ы всех наших проектов. Да, так и будет, но вот детали…. Итак, вот он наш будущий «корпоративный» POM:
Всё стандартно, но хочу обратить внимание не некоторые вещи:
С какими проблемами/непонятками обычно сталкиваются при использовании «корпоративного» POM’а?
Все это мы разберём в следующих частях это статьи. Сейчас кратко остановлюсь на двух последних пунктах.
Различие между «корпоративным» POM’ом и корневым POM отдельного проекта
«Корпоративный» POM описывает общие правила для всех ваших проектов в компании – как-то версия Java, зависимости и их версии, общие ограничения на проекты, за которыми может следить мавен, контакты на разработчиков и т.д. В «корпоративном» POM’е не должно быть информации («зависимостей») о конкретных внутренних проектах — их версий, специфичных профайлов и подобных вещей.
Как отслеживать и как часто обновлять версии внешних библиотек
Версии библиотек/плагинов можно легко отслеживать с помощью самого мавена (плагин versions-maven-plugin). Для этого добавим в наш «корпоративный» POM в секцию pluginManagement следующий фрагмент
А рядом с pom.xml создадим файл rules.xml со следующим содержимым
В принципе это делать не обязательно, и строчку file://$
После этого достаточно запустить команды versions:display-dependency-updates и versions:display-plugin-updates и получить результаты:
Кстати, вторая команда предупредит вас если вы используете какой-то плагин без указания его версии (правда, для этого ее надо запускать на проектных POM‘ах)
Вкратце это всё про «корпоративный» POM. В следующей части я планирую рассказать о типовой структуре проекта и, возможно, о организации деполоя артефактов в центральный и корпоративный репозитории.
Живой сайт об актуальных проектах
User Tools
Site Tools
Sidebar
Table of Contents
Maven FAQ
Основные ссылки по Maven:
Что такое сборка проекта, автоматизация сборки?
Что такое Maven? Как он работает?
Если собирать большие проекты с командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от этой зависимости и упростить написание скрипта, используют инструменты для сборки проекта.
Maven обеспечивает декларативную, а не императивную сборку проекта. То есть, в файлах проекта pom.xml содержится его описание, а не отдельные команды. Все задачи по обработке файлов в Maven выполняется через плагины.
Какие преимущества Maven?
Основные преимущества Maven:
Какие недостатки Maven?
Какими аспектами управляет Maven?
Вот основные аспекты, которыми позволяет управлять Maven:
Как узнать, какую версию Maven вы используете?
Версию можно узнать с помощью следующей команды:
Для чего был создан Maven?
Основной целью Maven является предоставление разработчику:
Структура и содержание проекта Maven указывается в специальном xml-файле, который назывется Project Object Model (POM), который является базовым модулем всей системы.
Какая структура каталогов в Maven?
| src/main/java | Application/Library sources | исходный код приложения или библиотеки |
| src/main/resources | Application/Library resources | ресурсы приложения или библиотеки |
| src/main/filters | Resource filter files | файлы с параметрами фильтрации ресурсов |
| src/main/webapp | Web application sources | исходный код веб-приложения |
| src/test/java | Test sources | исходный код тестов (юнит-тестов) |
| src/test/resources | Test resources | ресурсы юнит тестов |
| src/test/filters | Test resource filter files | файлы с параметрами фильтрации ресурсов для тестов |
| src/it | Integration Tests (primarily for plugins) | интеграционные тесты (в основном для плагинов) |
| src/assembly | Assembly descriptors | дескрипторы сборки |
| src/site | Site | вебсайт приложения (документация) |
| LICENSE.txt | Project’s license | лицензионное соглашение проекта |
| NOTICE.txt | Notices and attributions required by libraries that the project depends on | замечания и необходимые атрибуты библиотек, от зависит проект |
| README.txt | Project’s readme | краткое описание проекта |
Где хранятся файлы классов при компиляции проекта Maven?
Что такое pom.xml?
Во время выполнения задач, Maven ищет файл pom.xml в базовой директории проекта. Он читает его и получает необходимую информацию, после чего выполняет задачи.
содержит ссылку на схему XML, которая облегчает редактирование и проверку pom.xml :
Внутри тега project содержится основная и обязательная информация о проекте.
Какую информацию содержит pom.xml?
Среди информации которую содержит pom.xml, мы можем выделить следующие блоки:
Что такое супер POM?
Какие элементы необходимы для минимального POM?
Что такое зависимости в Maven?
Что такое артефакт в Maven?
Что такое плагин в Maven?
Что такое задача в Maven?
Что такое архетип в Maven?
Что такое репозитарий в Maven?
Какие типы репозитария существуют в Maven?
В Maven существуют три типа репозитариев:
Какая команда устанавливает JAR-файл в локальное хранилище (репозитарий)?
Какой порядок поиска зависимостей Maven?
Когда мы выполняем собрку проекта в Maven, автоматически начинается поиск необходимых зависимостей в следующем порядке:
Какие два файла настройки есть в Maven, как они называются и где расположены?
Что такое жизненный цикл сборки в Maven?
Назовите основные фазы жизненного цикла сборки Maven?
Когда Maven начинает сборку проекта, он проходит через определённую последовательность фаз сборки, и выполняет определенные задачи, которые указаны в каждой из фаз.
В Maven есть следующие три стандартных жизненных цикла:
Что делает команда mvn site?
создает веб-сайт проекта.
Что делает команда mvn clean?
эта команда очищает целевую директорию от созданных в процессе сборки файлов.
Из каких фаз состоит жизненный цикл сборки Clean?
Жизненный цикл сборки Clean состоит из следующих этапов:
Из каких фаз состоит жизненный цикл сборки Default (Build)?
Здесь также необходимо уточнить два момента:
Из каких фаз состоит жизненный цикл сборки Site?
Жизненный цикл сборки Site состоит из следующих этапов:
Что сделает команда «mvn clean dependency:copy-dependencies package»?
Порядок выполнения зависит от порядка вызова целей и фаз. Рассмотрим данную команду:
Аргументы clean и package являются фазами сборки, в то время как “ dependency:copy-dependencies ” является задачей.
Что такое профиль сборки (Build Profile)?
Используя профиль сборки Maven, мы можем настраивать сборку для различных окружений, таких как Development или Production.
Профили настраиваются в файле pom.xml с помощью элементов activeProfiles / profiles и запускаются различными методами.
Какие типы профилей сборки (Build Profiles) вы знаете?
В Maven существует три основных типа профилей сборки :
Как вы можете активировать профили сборки?
Профиль сборки Maven может быть активирован различными способами:
Для чего используются Maven плагины?
Maven плагины используются для:
Какие типы плагинов существуют в Maven?
В Maven существует два типа плагинов:
Когда Maven использует внешние зависимости?
Если необходимые файлы не найдены ни в центральном, ни на удалённом репозитарии, тогда для решения этой проблемы используются внешние зависимости.
Что нужно определить для внешней зависимости?
Внешние зависимости могут быть сконфигурированы в файле pom.xml таким же образом, как и другие зависимости, для этого нужно:
Какая команда создает новый проект на основе архетипа?
Переходим в нужную нам директорию и выполняем в терминале следющую команду:
Что такое SNAPSHOT в Maven?
В чем разница между snapshot и версией?
В случае со snapshot, Maven автоматически будет подтягивать крайний snapshot ( data-service:1.0-SNAPSHOT ) каждый раз, когда будет выполнятся сборка проекта.
Что такое транзитивная зависимость в Maven?
Как Maven определяет, какую версию зависимостей использовать, когда встречается множественный вариант выбора?
Что такое область видимости зависимостей (dependency scope)? Назовите значения dependency scope.
Существуют следующие области видимости зависимостей :
Какой минимальный набор информации нужен для составления ссылки зависимостей в разделе dependencyManagement?
Как сослаться на свойство(property) определенное в файле pom.xml?
Для чего нужен элемент в POM файле?
Элемент содержит информацию, необходимую для выполнения плагина.
Каким образом можно исключить зависимость в Maven?
Что является полным именем артефакта?
Если вы не определяете никакой информации, откуда ваш POM унаследует её?
Все POM-ы наследуются от родителя, несмотря на то, определен ли он явно или нет. Это базовый POM известный как “супер POM”, он содержит значения, которые наследуются по умолчанию.
При сборке проекта Maven постоянно проверяет наличие обновлений в интернете. Можете ли вы собрать проект без интернета?
Да, можете, если в вашем локальном репозитарии есть все необходимые для сборки артефакты.
Если при сборке проекта в тестах произошла ошибка, как собрать проект без запуска тестов?
Как запустить только один тест?
Вторая жизнь вместе с Maven
Думаю, для большинства хабражителей не будет откровением, что среди крупных софтварных разработок нередко встречаются технологии и языки значительно отстающие от передовых. К сожалению, это неизбежность, т. к. невозможно в какой-то момент взять и переписать несколько миллионов строк кода на другой язык или с применением более современного фреймворка.
Но в какой то момент отставание становится настолько существенным, что продукт перестает быть конкурентоспособен и постепенно исчезает с рынка. Именно такую ситуацию постепенного затухания мне и довелось наблюдать.
Здесь я хочу рассказать о том, как в конкретном случае я постарался оттянуть неизбежное и оживить разработку применив для этого сборщик проектов Maven.
Главным достоинством разработанной мною системы, пожалуй, можно назвать то, что небольшим количеством трудозатрат, можно при помощи Maven научить проект, реализованный на любом языке, собираться из отдельных Пакетов, соблюдающих свою версионность и автоматически обновляющихся при сборке проекта. Все что для этого нужно, это утилита командной строки, которая может скомпилировать исходник, а в случае скриптовых языков была бы полезна утилита валидации.
Итак дано:
— Система, «ядро» которой состоит из набора dll и отдается прикладным разработчикам без исходников.
— Прикладной язык программирования, который подобен Паскалю, но кроме стандартных возможностей Паскаля(из которых доступно далеко не все) позволяет использовать объекты, реализованные в dll «ядра». Данный прикладной язык компилируется в подобие байт кода и исполняется отдельной dll «ядра».
Таким образом, основная разработка ведется на описанном выше волшебном прикладном языке, все прелести которого, пожалуй, могли бы ужаснуть уважаемое сообщество, а «ядро» периодически(новая версия раз в пару месяцев) поставляется из головного офиса и не подлежит модификации.
Очень вероятно, что разработка и поддержание собственного языка программирования похожего на Паскаль и сделанного на базе Delphi возможно была плохой идеей, но 15-17 лет назад, когда все это начиналось, об этом никто не думал. Преследовались другие цели, которые в общем-то с успехом были достигнуты.
Сама система представляет из себя продаваемый заказчику продукт с сервером, клиентом и тонким клиентом. Естественно, большинство клиентов не удовлетворяются стандартным функционалом системы, поэтому существует несколько отделов прикладной разработки, “допиливающих”систему под их нужды. Каждым проектом занимается обособленная группа программистов. Взаимодействие и обмен опытом между группами катастрофически малы. Таким образом, каждая группа получает свой шанс переизобрести велосипед и наступить по десятому разу на одни и те же грабли.
Проведя анализ, стало понятно, что такое отсутствие взаимодействия отделов объясняется прежде всего нехваткой механизмов использования общего кода. Иными словами, если все-таки, происходил обмен опытом и исходниками между группами, то библиотека(исходник) просто копировалась в другой проект(продукт для друго клиента) и начинала жить самостоятельной жизнью, сохранив в себе все глюки и недоработки, которые присутствовали на момент копирования.
Для исправления ситуации было принято решение организовать репозиторий (хранилише) и систему сбора проекта с использованием набора библиотек общего кода(Пакетов).
В качестве инструмента для этого был выбран Maven, т. к. он по умолчанию выполняет схожие функции, имеет гибкий жизненный цикл и огромную гибкость плагинной системы.
Но обо всем по порядку
Главной проблемой, о которой я и не подозревал в начале своих изысканий, оказалось то, что Пакеты должны содержать в себе не скомпилированные в байт код файлы, а именно исходники, т.к. компиляция должна происходить именно под той версией «ядра», для которой они будут использоваться. Для простоты назовем наши прикладные исходники bpas. Это немного противоречит стандартному ЖЦ в Maven.
Немного о том как работает Maven
Жизненный цикл Maven достаточно полный, и набор фаз(phases) учитывает практически все этапы сборки проекта, которые могут потребоваться.
Причем пытаясь запустить какую-то фазу ЖЦ, например «mvn compile», я на самом деле запускаю всю цепочку фаз от validate (валидация проекта) до compile, не пропуская ни одной. Для каких-то фаз существуют так называемые плагины по умолчанию, которые будут вызваны несмотря на то, что в pom.xml(основной файл Maven проекта) существует только заголовок и ни одного указания на запуск плагинов.
Здесь стоит отдельно отметить тот факт, что Maven — это полностью плагинная система. Иными словами, он не умеет практически ничего, кроме запуска плагинов, а вот они уже умеют делать потрясающе много. Получается, что когда мы хотим научить Maven каким- то особенностям сборки проекта, мы должны добавить в pom.xml указание на запуск нужного плагина в нужную фазу и с нужными параметрами.
Вот такой абсолютно валидный пустой pom.xml, несмотря на свою пустоту, при получении команды mvn deploy запустит Плагин инициализации, компиляции, упаковки и деплоя Java исходников из папки src/main.
Основной политикой использования в Maven является то, что для любого действия есть свои параметры по умолчанию и дополнительные настройки требуются только в том случае, когда этих умолчаний не хватает или они грубо нарушаются. В моем случае пришлось отказаться от очень многих умолчаний, поэтому pom.xml уже не выглядит так скромно.
Построение нового ЖЦ в pom.xml
Для реализации пакетов был подобран следующий жизненный цикл.
initialize (инциализация) – Читаем настройки из конфиг(property или key = value) файла и добавляем их в тег properties. О теге properties поговорим чуть позже.
generate-sources (генерация исходного кода) – Загружаем и распаковываем из zip все Пакеты, которые являются зависимостями данного пакета/проекта, в отдельную директорию для последующей компиляции вместе с исходниками текущего пакета/проекта.
compile (компиляция) – Запускаем свой плагин компиляции для наших bpas, который определяет правильный порядок компиляции и запускает компилятор командной строки для нашего языка. Кратко я расскажу о собственном плагине ниже, но гайд по его написанию предлагаю вынести за пределы данной статьи.
assembly (сборка) – запаковываем пакет, состоящий из исходников bpas в zip с сохранением структуры подкаталогов исходных файлов.
deploy (в нашем случае выгрузка в репозиторий) – Собранный на фазе assembly zip отправляется в локальный репозиторий Maven с добавлением к нему pom.xml и другой информации по пакету. Данная процедура почти идентична нормальному deploy jar файла, но с особыми параметрами.
clean (очистка) – Данная фаза не входит в общий ЖЦ фаз сборки, а стоит несколько особняком, но поскольку она также была модернизирована, ее тоже стоит упомянуть. Кроме стандартного удаления директории, в которой лежат скомпилированные файлы. (targetDirectory), потребовалось удалять тот мусор, который образуется в процессе скачивания и распаковки пакетов-зависимостей.
Общая структура pom.xml
Я условно делю pom.xml на две части: заголовок и сборка.
Заголовок представляет из себя идентификацию пакета (groupId, artifactId, version), свойства (properties, которые выполняют роль внутренних констант), указание локального репозитория (distributionManagement), указание локального репозитория плагинов (pluginRepositories), указание локального репозитория пакетов (repositories) и указание зависимостей этого пакета (dependencies). При этом все три репозитория могут указывать на одно и то же хранилище, но принципиально это три разные сущности, каждую из которых нужно указывать отдельно. Так например, мы можем решить хранить плагины отдельно от остального кода, а для доступа к пакетам в хранилише использовать http доступ, тогда как «деплоить» туда мы будет как в файловое хранилище.
Сборка (тег build) — это вторая часть pom.xml, в которой настраиваются особенности обработки той или иной фазы жизненного цикла различными плагинами с недефолтными настройками. Кроме этого там настраиваются директории и параметры, которые будут участвовать в сборке проекта:
sourceDirectory – директория, в которой находятся исходники для компиляции.
finalName – конечное имя файла после запаковки в архив.
directory – рабочая директория, в которую будут положены скомпилированные файлы.
Кроме этого еще раз хочу напомнить, что для всех этих параметров, существуют значения по умолчанию, и их отдельное указание в нашем случае требуется только потому, что они должны отличаться от этих самых умолчаний.
Реализация ЖЦ в теге build
Теперь вернемся к определенному нами ЖЦ и посмотрим, как каждая из фаз жизненного цикла реализована при помощи вызова нужного плагина с той конфигурацией, которая нам нужна.
initialize
Тут опять давайте немного отвлечемся и отдельно упомянем тег properties. Объясним, зачем он нужен и как используется.
Если говорить очень грубо, то этот тег похож на объявление констант, которые в дальнейшем будут использоваться в нашей программе (pom.xml). Но попадать туда значения могут тремя разными способами. И у каждого способа есть приоритет, определяющий, какое в итоге значение будет в тот момент, когда оно реально потребуется.
Низший приоритет у прямой записи свойств в тег properties, например так:
Более высокий приоритет у прямого задания параметров при запуске Maven, примерно так «mvn –DhelloText=Hi initialize»
При запуске Maven с таким параметром исходное значение тега helloText будет заменено на переданное в строке запуска для текущего сеанса, т.е. в xml оно не сохранится. Если такой константы вообще не существовало, то на этот сеанс она будет существовать и может быть использована. Значения всех несуществующих констант — пустая строка.
Наивысшим приоритетом обладает добавление значений в тег proprties плагинами в текущей сессии. Они так же не сохраняться в pom.xml. Именно этот механизм и будет использован нами для вынесения отдельных настроек сборки в properties файл, содержащий “имя=значение”
Для этого используется плагин properties-maven-plugin
generate-sources
На стадии генерации исходников мы рекурсивно загружаем из репозитория и распаковываем все необходимые нам Пакеты, которые указаны в зависимостях. Опять же самим практически ничего делать не нужно. Все за нас сделает плагин после указания ему правильных настроек.
Конструкция $ означает, что нужно взять значение из тега “/project/properties/packagesPath”.
Отдельно хочу отметить, что использования плагина maven-assembly-plugin для распаковки считается deprecated и не рекомендуется к использованию в Maven 3. Вместо него используется maven-dependency-plugin с настройками аналогичными указанным выше. Я же использую более старую версию плагина, чтобы еще раз наглядно показать, как один и тот же плагин настраивается на выполнение нескольких задач из его ассортимента.
compile
Со стадией компиляции пришлось изрядно повозиться, но основные трудности возникли с написанием собственного плагина компиляции. Пошаговая инструкция по написанию собственного плагина для Maven — это тема для отдельной статьи, поэтому сейчас мы не будем заострять на этом внимание. В конце-концов изложенный здесь материал может быть использован и для скриптовых языков, компиляция которым вообще не требуется.
Одно можно сказать наверняка, как бы вы не старались, не удастся отключить запуск родного плагина maven-compile-plugin, призвание которого компилировать исходники на Java( Не рассматривая возможности редактирования superPom.xml). Итак настройки моего плагина компиляции выглядят следующим образом:
используемые параметры:
protectionServer — сервер защиты, без которого невозможен запуск компилятора командной строки.
protectionAlias — секция используемой лицензии сервера защиты.
bpasccPath — полный или относительный путь к компилятору командной строки.
binaryVersion — Версия, которая будет «вмонтирована» в скомпилированную библиотеку.
Это далеко не все настройки моего плагина, но как я и говорил, это тема для отдельной большой статьи. В принципе секцию configuration можно было вообще не указывать и тогда все параметры, которые необходимы плагину, были бы проинициализированы плагином значениями по умолчанию, что соотвествует основной концепции Maven.
assembly
При прохождении фазы assembly у Maven по умолчанию настроен запуск maven-assembly-plugin, явно указав его запуск в фазе assembly в теге build, мы можем переопределить его настройки и заставить работать на нас. Этот же плагин мы использовали для распаковки пакетов перед компиляцией, поэтому теперь я приведу полную версию настроек этого плагина, включающую и запаковку и распаковку.
packagesDirName — это константа из /project/properties файла pom.xml
Отдельно хочу отметить, что такое вынесение настроек запаковки в отдельный файл, позволило мне создать один конфиг запаковки на все Пакеты, что крайне удобно.
deploy
Фаза deploy так же запускается Maven’ом независимо от того, указали ли мы настройки этого плагина или нет. Переопределив их, мы и этот плагин заставили работать на себя.
С такими ручными настройками maven-deploy-plugin позволяет любой файл(или даже группу файлов) выложить в репозиторий Maven как валидную библиотеку(Пакет). Теперь разберем настройки по порядку.
file — файл, который будет отправлен в репозиторий Maven как Пакет.
url — путь к репозиторию Maven
repositoryId — идентификатор репозитория, в который будет производиться депллой.
groupId, artifactId, version — стандартная идентификация пакета в репозитории Maven. Именно по этим трем параметрам можно однозначно идентифицировать библиотеку. packaging – функционал деплой так же включает в себя запаковку файлов, которые будут отправлены в репозиторий, поэтому необходимо снова указать ему zip, чтобы он ничего не делал с пакетом, иначе распакует и запакует как jar :-).
pomFile – если данный параметр указан, то в комплект к Пакету будет добавлен тот файл, который мы укажем как pom.xml, при этом его изначальное имя может быть другим. Сохранять оригинальный pom.xml выгодно по многим причинам, поэтому мы не будем брезговать данной возможностью.
clean
Фаза clean, как я уже говорил, не входит в стандартный ЖЦ. Изначальная ее задача состоит в том, чтобы после выполнения команды mvn clean в проекте не осталось никаких следов жизнедеятельности. В нашем случае кроме стандартной папки targetSource(указана в теге build) требуется так же удалить все Пакеты, которые были «слиты» как зависимости для успешной компиляции пакета/проекта.
directory — собственно указание директории, которую необходимо удалить. Надо отметить, что тут создатели плагина отошли от общепринятой концепции, и явное указание настроек плагина не отменяет его действий по умолчанию. Но в данном случае, это очень хорошо, т. к. избавляет нас от лишний настроек.
Памятуя о том, как поначалу тяжело разбираться с отдельными ветками настроек, ниже приведу полный текст pom.xml одного из пакетов.
Итоги
Несмотря на то, что я сам остался чертовски доволен своей работой, я готов признать, что в данном виде система пакетной сборки проекта еще далека от совершенства, однако, приведенное описание достаточно иллюстрирует реализацию полного жиненного цикла пакета/проекта. Фактически это работоспособный каркас, поверх которого можно почти неограниченно расширять возможности.
