На просторах сети вообще и хабра в частности Я видел не одну тему, посвященную Maven. И повсюду, где было обсуждение , такие вопросы:
- Каковы преимущества его использования в проекте типа X?
- Чем он лучше Ant/Make/sh?
- Что мне делать, если я хочу использовать antlr/JAX-WS/XDoclet в своем проекте?
Мне кажется очень важным понимать, что когда говорят Maven, они имеют в виду три довольно слабо связанных между собой вещи:
- ПОМ.
Объектная модель проекта.
Модель проекта – она описывает, из чего состоит проект и как работает его жизненный цикл.
- Хранилища артефактов.
Места хранения продуктов сборки программных модулей вместе с метаданными.
- Утилита mvn и плагины к ней.
Фактически инструмент для сборки проектов управления жизненным циклом модулей.
П.
О.
М.
Это общая модель проекта.
В нем описываются такие общие характеристики, как название, версия, авторы и их контактная информация, система управления системой проекта и вообще связанные с ним сетевые ресурсы, тип проекта (например, библиотека или веб-модуль, в оригинальной терминологии называется упаковкой, хотя это влияет не только на тип получаемого артефакта), подключения к другим проектам, плагины, использованные в сборке и описания как их использовать.
Два компонента этой модели кажутся мне особенно важными.
Соединения с другими модулями
POM допускает три типа отношений с другими модулями: зависимость, включение и наследование.Зависимость , эта связь говорит о том, что для некоторых фаз жизненного цикла нашего модуля требуются некие артефакты модулей-зависимостей (вышло абстрактно — уже страшно).
Что именно требуется и на каком этапе жизненного цикла определяется так называемой областью зависимости.
Maven понимает несколько предопределенных областей действия и позволяет добавлять свои собственные.
В качестве примера я ограничусь одной областью: компиляция — там говорится, что бинарные сборки зависимостей требуются при компиляции, выполнении теста и во время выполнения.
Включение — говорит о том, что связанный модуль является неотъемлемой частью нашего модуля.
Чтобы наш модуль прошел определенную фазу своего жизненного цикла, его член также должен пройти эту фазу.
Классическим примером является корпоративный модуль, включающий веб-модуль, пакет с EJB и общую библиотеку.
Очевидно, что для его сборки требуется сборка каждого из входящих в комплект модулей.
Наследование .
Такое соединение подразумевает передачу части модели предка наследнику.
Правила передачи несколько запутаны, но основной принцип заключается в том, что значение параметра модели-предка становится значением по умолчанию для дочерней модели.
Пример из моей практики: был создан модуль, в котором установлена версия JDK для компиляции проектов, внутренние репозитории для результатов, набор правил проверки соответствия исходного кода стандарту кодирования, его предполагалось использовать (и в кое-где он действительно использовался ;)) как родительский для всех разработанных в рамках проекта модулей.
Описание плагинов, используемых при сборке
Описание состоит из названия задействованного плагина, некоторых его настроек (они определяются плагинами индивидуально) и фактических целей, которые он выполняет на каждом этапе жизненного цикла (подробное описание идей, лежащих в основе этих плагинов, см.ниже).
условия).
Этот элемент несколько чужд общей идее POM — он несет в себе не декларативное описание модуля, а инструкции по его сборке конкретным инструментом.
Полученные результаты
- POM — это распространенная унифицированная модель описания программных модулей.
- Он поддерживает хранение не только атрибутов отдельных модулей, но и высокоуровневых связей между ними.
- Он также содержит информацию об инструментах, необходимых для поддержки жизненного цикла модуля.
Хранилища артефактов
Репозитории артефактов — это специальные хранилища результатов сборки, предназначенные для облегчения поиска нужного артефакта (по имени, версии, типу артефакта).Они позволяют группе разработчиков использовать наработки друг друга без необходимости иметь копии исходных кодов своих модулей и строить дерево зависимостей с нуля.
Репозитории, совместимые с Maven, стали стандартом де-факто для публикации результатов различных проектов с открытым исходным кодом.
Следует отметить, что pom-файлы, содержащие модель проекта, также являются артефактами и могут храниться в репозиториях наравне со всеми остальными (фактически всегда хранятся, по крайней мере, их урезанные версии, содержащие только идентификацию модуля и зависимости).
Таким образом, репозиторий также является источником информации (по крайней мере, достаточной для распространения) о хранящихся в нем модулях.
Итак, какие бонусы нам дают:
- Структурированное хранение артефактов, их каталогизация.
- Повторное использование артефактов.
Утилита управления жизненным циклом
Название получилось довольно пафосным, но вполне соответствует высокой миссии и сложности предмета.Прежде чем углубляться в его функции, необходимо немного ознакомиться с теорией организации жизненного цикла модуля в Maven. Жизненный цикл — это весь набор операций над модулем от инициализации сборки до развертывания.
В течение жизненного цикла над модулем выполняются определенные операции и генерируются некоторые артефакты.
Жизненный цикл делится на фазы.
Каждая фаза предполагает перевод модуля в новое состояние в результате его прохождения и появления новых артефактов.
Каждый предыдущий этап подготавливает основу для следующего.
Список фаз по сути является частью POM, но глобальным, общим для всех модулей.
Полный список приводить бессмысленно, но в качестве примера приведу несколько этапов (названных, на мой взгляд, довольно интуитивно :) ) в порядке их появления: компиляция,.
тестирование,.
развертывание.
В рамках каждого этапа реализуется определенный набор целей в зависимости от модели конкретного модуля.
Цель — это конкретная операция над исходными кодами и/или артефактами.
Теперь к самой утилите.
Она отвечает за реализацию жизненного цикла на основе модели проекта.
Состоит из двух основных компонентов:
- Во-первых, из очень маленького ядра, в котором описаны (жестко запрограммированные, как говорят обыватели) основные принципы проектирования проектов, цели по умолчанию для этапов стандартных типов проектов, рабочая среда для плагинов (интерфейсы доступа к моделям, репозиториям, ФС, настройкам и т. д.) .
П.
).
- Во-вторых, от плагинов.
На самом деле они содержат код, который достигает поставленных целей.
Практически весь внешний функционал mvn реализован ими.
Именно они генерируют, компилируют, тестируют, упаковывают и т. д. и т. п.
Например, мы говорим компилировать и нам компилируют, причем не только то, что вышло из СВК, но и генерируют нужные вещи, например с помощью wsimport, и результаты тоже компилируются.
Вы также можете попросить выполнить отдельную задачу для конкретного плагина.
Например, есть плагин для генерации проектов Eclipse, задача «сгенерировать проект» по умолчанию не привязана ни к одной фазе, а вызывается заинтересованными лицами вручную.
Еще одна чрезвычайно интересная функция mvn — создание шаблона проекта на основе архетипа.
Архетип — это обобщенный шаблон проекта, традиционно ориентированный на его структуру и используемые плагины.
Например, есть стандартные архетипы java-библиотеки, веб-модуля и нестандартные, например приложение Grails. Важно понимать разницу между архетипом и типом проекта.
Архетип — это лишь шаблон исходной структуры и отдельных частей проекта; после создания проекта не остается никакой информации о его архетипе.
Тип проекта, наоборот, является частью модели, которая используется на протяжении всего жизненного цикла.
Что это дает?
Итак, мы определили три столпа Maven. Что они дают нам вместе?- Концентрация информации о модуле в одном месте и в одном формате.
Здесь не все гладко, но многие IDE умеют импортировать проекты из POM, большинство серверов автокомпиляции (непрерывная интеграция, как говорят адепты XP) также могут использовать их для добавления проекта.
- Единая система идентификации модулей.
Очень просто и очень важно.
У нас больше нет обозначений типа bugfix-branch нашего-супер-проекта, собранных в 23:00 в прошлую субботу.
- Один инструмент. Хотя, честно говоря, это не уникальная особенность Maven. Не могу удержаться от повторения банальной истины: проект необходимо собирать стандартными и портативными средствами.
Создание любимой IDE Первого разработчика проекта — это путь в ад.
- Автоматическое управление зависимостями.
Связывать исходный код проекта с бинарными сборками чего-либо — очень печальная практика.
Особо следует отметить трудности с поддержкой репозиториев исходников (сколько магнитных лент занимает ваша резервная копия svn?))).
Изобретать колесо в виде собственных репозиториев или скриптов, подтягивающих исходные зависимости, тоже не лучшее решение в эпоху, когда по просторам вселенной бороздят космические корабли.
- Повторное использование решений, связанных с процедурой проектирования и сборки проектов.
Благодаря наследованию и включению проектов мы можем повторно использовать однажды разработанные модели проектов, настройки, связанные с инфраструктурой и инструментами, принятыми в нашей компании.
Использование архетипов позволяет автоматизировать этап создания новых проектов, сэкономить время на подготовке структуры проекта и минимизировать ошибки при использовании внешних моделей.
- Готовый инструмент для управления результатами работы и удобства последующего использования.
Мы настраиваем инфраструктуру соответствующим образом, и каждая сборка оказывается в нужном месте и доступна для дальнейшего использования.
Вам нужно проверить работоспособность разных версий/веток модулей большого проекта? Мы просто редактируем зависимости в POM.
Заключение
Я как-то местами отклонился от центрального вопроса и вплотную занялся вопросом «как», ну да ладно.Из всей приведенной выше информации можно сделать простой, но почему-то очень редкий вывод. Maven не является утилитой для создания Java-приложений.
Maven — это платформа для автоматизации широкого спектра задач при поддержке проекта.
Это никак не связано с языком и платформой, более того, совершенно не требуется ничего собирать.
Описывая модели или создавая плагины, вы превращаете их в тот или иной инструмент. Да, принятая в нем модель по умолчанию — это сборка Java-модулей, но это всего лишь дефолты… Надеюсь, что после прочтения темы каждый сможет уверенно ответить на вопросы, заданные в начале ;) P.S. Мне также было бы интересно услышать о вашем опыте нестандартного использования Maven. Есть идея в будущем создать пост с примерами интересных и необычных вариантов использования.
Теги: #maven #управление сборкой #pom #java
-
Обзор Метатрейдера. Трейлинг-Стоп.
19 Oct, 24 -
Мысли О Webm
19 Oct, 24 -
Google Приобрела Интерфейс В Стиле Mac Os X
19 Oct, 24 -
Ipaas — Облачные Esb… Или Нет?
19 Oct, 24 -
Версия 1.0.6
19 Oct, 24
