Что такое pom xml
Что такое pom xml
Introduction to the POM
What is a POM?
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is target ; the source directory, which is src/main/java ; the test source directory, which is src/test/java ; and so on. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.
Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.
Super POM
The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.
You can see the Super POM for Maven 3.6.3 in Maven Core reference documentation.
Minimal POM
The minimum requirement for a POM are the following:
Also, as mentioned in the first section, if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value «jar» would be used.
Furthermore, you can see that in the minimal POM the repositories were not specified. If you build your project using the minimal POM, it would inherit the repositories configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from https://repo.maven.apache.org/maven2 which was specified in the Super POM.
Project Inheritance
Elements in the POM that are merged are the following:
The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.
Example 1
The Scenario
As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact, com.mycompany.app:my-module:1.
And let us specify their directory structure as the following:
Note: my-module/pom.xml is the POM of com.mycompany.app:my-module:1 while pom.xml is the POM of com.mycompany.app:my-app:1
The Solution
Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of com.mycompany.app:my-module:1,we will have to modify com.mycompany.app:my-module:1’s POM to the following configuration:
Notice that we now have an added section, the parent section. This section allows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our parent POM.
Alternatively, if you want the groupId or the version of your modules to be the same as their parents, you can remove the groupId or the version identity of your module in its POM.
This allows the module to inherit the groupId or the version of its parent POM.
Example 2
The Scenario
However, that would work if the parent project was already installed in our local repository or was in that specific directory structure (parent pom.xml is one directory higher than that of the module’s pom.xml ).
But what if the parent is not yet installed and if the directory structure is as in the following example?
The Solution
To address this directory structure (or any other directory structure), we would have to add the element to our parent section.
Project Aggregation
Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent’s modules as well. To do Project Aggregation, you must do the following:
Example 3
The Scenario
Given the previous original artifact POMs and directory structure:
The Solution
If we are to aggregate my-module into my-app, we would only have to modify my-app.
Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.
Example 4
The Scenario
But what if we change the directory structure to the following:
How would the parent POM specify its modules?
The Solution
Project Inheritance vs Project Aggregation
If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you’d only have to build the parent and the rest will follow.
But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules. You’d just have to apply all three rules:
Example 5
The Scenario
Given the previous original artifact POMs again,
Что такое pom xml
Quick Overview
This is a listing of the elements directly under the POM’s project element. Notice that modelVersion contains 4.0.0. That is currently the only supported POM version, and is always required.
The Basics
Maven Coordinates
The three elements given above point to a specific version of a project, letting Maven know who we are dealing with, and when in its software lifecycle we want them.
packaging
POM Relationships
One powerful aspect of Maven is its handling of project relationships: this includes dependencies (and transitive dependencies), inheritance, and aggregation (multi-module projects).
Dependency management has a long tradition of being a complicated mess for anything but the most trivial of projects. «Jarmageddon» quickly ensues as the dependency tree becomes large and complicated. «Jar Hell» follows, where versions of dependencies on one system are not equivalent to the versions developed with, either by the wrong version given, or conflicting versions between similarly named jars.
Maven solves both problems through a common local repository from which to link projects correctly, versions and all.
Dependencies
The cornerstone of the POM is its dependency list. Most projects depend on others to build and run correctly. If all Maven does for you is manage this list, you have gained a lot. Maven downloads and links the dependencies on compilation, as well as on other goals that require them. As an added bonus, Maven brings in the dependencies of those dependencies (transitive dependencies), allowing your list to focus solely on the dependencies your project requires.
Since the dependency is described by Maven coordinates, you may be thinking: «This means that my project can only depend upon Maven artifacts!» The answer is, «Of course, but that’s a good thing.» This forces you to depend solely on dependencies that Maven can manage.
There are times, unfortunately, when a project cannot be downloaded from the central Maven repository. For example, a project may depend upon a jar that has a closed-source license which prevents it from being in a central repository. There are three methods for dealing with this scenario.
Notice that an address is still required, only this time you use the command line and the install plugin will create a POM for you with the given address.
As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier jdk11 and the second one with jdk8 such that clients can choose which one to use.
Another common use case for classifiers is to attach secondary artifacts to the project’s main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files.
In the shortest terms, optional lets other projects know that, when you use this project, you do not require this dependency in order to work correctly.
Dependency Version Requirement Specification
Dependencies’ version elements define version requirements, which are used to compute dependency versions. Soft requirements can be replaced by different versions of the same artifact found elsewhere in the dependency graph. Hard requirements mandate a particular version or versions and override soft requirements. If there are no versions of a dependency that satisfy all the hard requirements for that artifact, the build fails.
Version requirements have the following syntax:
Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project. If no version satisfies all the hard requirements, the build fails.
Version Order Specification:
If version strings are syntactically correct Semantic Versioning 1.0.0 version numbers, then in almost all cases version comparison follows the precedence rules outlined in that specification. These versions are the commonly encountered alphanumeric ASCII strings such as 2.15.2-alpha. More precisely, this is true if both version numbers to be compared match the «valid semver» production in the BNF grammar in the semantic versioning specification. Maven does not consider any semantics implied by that specification.
Important: This is only true for Semantic Versioning 1.0.0. The Maven version order algorithm is not compatible with Semantic Versioning 2.0.0. In particular, Maven does not special case the plus sign or consider build identifiers.
Splitting and Replacing Examples:
The version order is the lexicographical order on this sequence of prefixed tokens, the shorter one padded with enough «null» values with matching prefix to have the same length as the longer one. Padded «null» values depend on the prefix of the other version: 0 for ‘.’, «» for ‘-‘. The prefixed token order is:
» alpha » beta » milestone » rc » = » cr » snapshot » final » = » ga » sp «
End Result Examples:
Note: Contrary to what was stated in some design documents, for version order, snapshots are not treated differently than releases or any other qualifier.
Version Order Testing:
The maven distribution includes a tool to check version order. It was used to produce the examples in the previous paragraphs. Feel free to run it yourself when in doubt. You can run it like this:
Exclusions
It is also sometimes useful to clip a dependency’s transitive dependencies. A dependency may have incorrectly specified scopes, or dependencies that conflict with other dependencies in your project. Using wildcard excludes makes it easy to exclude all a dependency’s transitive dependencies. In the case below you may be working with the maven-embedder and you want to manage the dependencies you use yourself, so you clip all the transitive dependencies:
Inheritance
One powerful addition that Maven brings to build management is the concept of project inheritance. Although in build systems such as Ant inheritance can be simulated, Maven makes project inheritance explicit in the project object model.
Notable elements which are not inherited include:
Notice the relativePath element. It is not required, but may be used as a signifier to Maven to first search the path given for this project’s parent, before searching the local and then remote repositories.
To see inheritance in action, just have a look at the ASF or Maven parent POM’s.
Краткое знакомство с Maven
Maven — инструмент для автоматизации сборки проектов. С ним работают в основном Java-разработчики, хотя есть плагины для интеграции с C/C++, Ruby, Scala, PHP и другими языками. В статье будут рассмотрены особенности и область применения Maven, описан процесс установки и начала работы, а также разобрана структура файла описания проекта.
Назначение и особенности
Собрать на Java проект уровня «Hello, world!» можно и с помощью командной строки. Но чем сложнее разрабатываемое ПО и чем больше оно использует сторонних библиотек и ресурсов, тем сложнее будет команда для сборки. Maven разработан для облегчения этой работы.
Одна из главных особенностей фреймворка — декларативное описание проекта. Это значит, что разработчику не нужно уделять внимание каждому аспекту сборки — все необходимые параметры настроены по умолчанию. Изменения нужно вносить лишь в том объёме, в котором программист хочет отклониться от стандартных настроек.
Ещё одно достоинство проекта — гибкое управление зависимостями. Maven умеет подгружать в свой локальный репозиторий сторонние библиотеки, выбирать необходимую версию пакета, обрабатывать транзитивные зависимости.
Разработчики также подчёркивают независимость фреймворка от ОС. При работе из командной строки параметры зависят от платформы, но Maven позволяет не обращать внимания на этот аспект.
При необходимости систему сборки можно настроить под собственные нужды, используя готовые плагины и архетипы. А если ничего подходящего не нашлось — можно написать свои.
В этой статье мы будем работать с Maven с помощью командной строки, однако этот фреймворк также интегрирован в Eclipse, IntelliJ IDEA, NetBeans и другие IDE.
Установка, настройка и создание стандартного проекта
Скачать Maven можно с официальной страницы проекта. Там же вас познакомят с минимальными требованиями — на машине должен быть установлен JDK, а также потребуется свободное место на диске, около 500 мегабайт. Это место нужно не для самой установки, оно будет использовано для создания локального репозитория.
На странице скачивания вы найдёте несколько разных архивов, для первого раза лучше использовать готовые бинарники. Исходники потребуются, если захочется всё сломать покопаться в Maven.
В ОС на основе Unix переменную среды можно добавить консольной командной:
Создаём папку для нового проекта и переходим в неё. Далее создаём новый проект. Для этого в консоли выполните команду:
Выглядит довольно сложно, поэтому разберём её по порядку.
Выполнив команду, Maven сгенерирует следующую структуру проекта:
Исходники нашего проекта будут лежать в папке src/main/java (и сейчас там уже есть автоматически сгенерированный файл), но нам сейчас интереснее файл pom.xml в корневом каталоге. Это и есть тот самый файл описания проекта, на основе которого осуществляются все операции Maven. Он написан на языке POM, входящим в семейство XML:
Разберёмся, что всё это значит.
Что значат теги в pom.xml
Кстати, это хороший повод поговорить о жизненном цикле проекта. Maven выполняет сборку последовательными фазами. Приводим их названия на английском, так как они используются в качестве команд.
Поздравляем! Вы собрали проект с помощью 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 одного из пакетов.
Итоги
Несмотря на то, что я сам остался чертовски доволен своей работой, я готов признать, что в данном виде система пакетной сборки проекта еще далека от совершенства, однако, приведенное описание достаточно иллюстрирует реализацию полного жиненного цикла пакета/проекта. Фактически это работоспособный каркас, поверх которого можно почти неограниченно расширять возможности.