Меню Закрыть

Что такое maven java

Содержание

Apache Maven
Тип Автоматизация сборки и система управления пакетами
Разработчик Apache Software Foundation
Написана на Java[3][4]
Операционная система кроссплатформенность
Первый выпуск 30 марта2002
Аппаратная платформа Java Virtual Machine
Последняя версия
  • 3.6.1 ( 4 апреля2019 ) [1][2]
Лицензия Apache License 2.0
Сайт maven.apache.org​ (англ.)

Apache Maven — фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (англ. Project Object Model ), являющемся подмножеством XML [5] . Проект Maven издаётся сообществом Apache Software Foundation, где формально является частью Jakarta Project.

Название системы является словом из языка идиш, смысл которого можно примерно выразить как «собиратель знания» [6] .

Maven обеспечивает декларативную, а не императивную (в отличие от средства автоматизации сборки Apache Ant) сборку проекта. В файлах описания проекта содержится его спецификация, а не отдельные команды выполнения. Все задачи по обработке файлов, описанные в спецификации, Maven выполняет посредством их обработки последовательностью встроенных и внешних плагинов.

Maven используется для построения и управления проектами, написанными на Java, C#, Ruby, Scala, и других языках [7] .

Среди примечательных альтернатив — система автоматической сборки Gradle, построенная на принципах Apache Ant и Maven, но использующая специализированный DSL на Groovy вместо POM-конфигурации.

Содержание

История разработки [ править | править код ]

Maven был создан канадцем Ясоном ван Зилом ( Jason van Zyl ) и организованной им фирмой Sonatype. Он начался как подпроект Apache Turbine в 2002 году, в 2003 году Maven был квалифицирован как Apache-проект верхнего уровня, тогда же появилась его первая версия — Maven 1.x, опубликованная 13 июля 2004 года как версия 1.0. Это происходило, однако, так быстро, что некоторые частности оказались непродуманными, например, слишком много конфигурации, проблемы с производительностью.

Поэтому концепция была доработана и с 2005 года началась параллельная разработка Maven 2.x, которая была сдана в версии 2.0 19 октября 2005 года. [8]

Maven 1.x не разрабатывается дальше и ограничивается поддержкой пользователей и устранением ошибок. [9]

Разработка Maven 3.0 началась в 2008 году. После восьми альфа-релизов, первая бета-версия Maven 3.0 была опубликована в октябре 2010 года. Особенное внимание было уделено её обратной совместимости с Maven 2. Для большинства проектов переход от версии Maven 2 к версии Maven 3 не требует никаких изменений [10] .

Разработка Maven происходит в следующих подпроектах:

  • Maven 1.x и Maven 2.x — старые версии Maven.
  • Maven 3.x развивает текущую линию продуктов Maven [10] .
  • Plugins разрабатывает большинство maven-плагинов.
  • Shared Components изготовляет компоненты программного обеспечения, которые могут использоваться всеми другими подпроектами.
  • Ant Tasks позволяет использовать возможности Ant из Maven.
  • Doxia — фреймворк для генерации контента из форматов Almost Plain Text (APT), Confluence, DocBook, FML (FAQ Markup Language), LaTeX, Rich Text Format (RTF), TWiki, XDoc и XHTML.
  • SCM (Source Code Management) разрабатывает программное обеспечение для подключения Apache к различным системам версионирования как CVS или Subversion.
  • Surefire разрабатывает тест-фреймворк для Maven-а.
  • Wagon готовит абстракцию коммуникационных протоколов как «доступ к файлам», HTTP или FTP.

Объектная модель описания проекта [ править | править код ]

Информация для сборки проекта, поддерживаемого Apache Maven, содержится в XML-файле с названием pom.xml. При запуске Maven проверяет, содержит ли конфигурационный файл все необходимые данные и все ли данные синтаксически правильно записаны.

Пример файла pom.xml:

Минимальная конфигурация включает версию конфигурационного файла, имя проекта, его автора и версию [11] . С помощью pom.xml конфигурируются зависимости от других проектов, индивидуальные фазы процесса построения проекта (build process), список плагинов, реализующих порядок сборки [11] .

Крупные проекты могут быть поделены на несколько модулей, или подпроектов, каждый со своим собственным POM. Операции над модулями могут выполняться через общий корневой POM единой командой.

POM-файлы подпроектов могут наследовать конфигурацию от других файлов конфигурации. В то же время все файлы конфигурации обязательно наследуются от «Супер POM» файла [12] по умолчанию. Супер POM обеспечивает конфигурацию по умолчанию, например, стандартная структура каталогов, используемые по умолчанию плагины, привязка к фазам жизненного цикла и прочее.

Основные концепции [ править | править код ]

Соглашения по конфигурации [ править | править код ]

Maven поддерживает принцип соглашения по конфигурации, заключающийся в том, что рассматриваемые аспекты нуждаются в конфигурации тогда и только тогда, когда этот аспект не удовлетворяет некоторой спецификации. Как следствие, это позволяет сократить количество требуемой конфигурации без потери гибкости. Одним из следствий применения данного принципа является то, что отсутствует необходимость указывать пути к файлам в явном виде, что упрощает содержимое pom.xml. Однако, почти все стандарты, на которые опирается Maven, могут быть изменены индивидуальной конфигурацией [13] [14] .

Архетипы [ править | править код ]

Maven использует принцип Maven-архетипов (англ. Archetypes). Архетип — это инструмент шаблонов, каждый из которых определён паттерном или моделью, по аналогии с которой создаются производные. [15]

Стандартная структура каталогов — одна из реализаций принципа архетипов в Maven. Следующая структура показывает важнейшие каталоги для проекта на Java [16] :

  • Корневой каталог проекта: файл pom.xml и все дальнейшие подкаталоги
  • src: все исходные файлы
  • src/main: исходные файлы собственно для продукта
  • src/main/java: исходный текст на Java
  • src/main/resources: другие файлы, которые используются при компиляции или исполнении, например properties-файлы
  • src/test: исходные файлы, необходимые для организации автоматического тестирования
    • src/test/java: JUnit-тест-задания для автоматического тестирования
    • target: все создаваемые в процессе работы Мавена файлы
      • target/ > Жизненный цикл [ править | править код ]
      • Жизненный цикл maven-проекта — это список поименованных фаз, определяющий порядок действий при его построении. Жизненный цикл Maven содержит три независимых порядка выполнения: [17]

        • clean — жизненный цикл для очистки проекта. Содержит следующие фазы:
          1. pre-clean
          2. clean
          3. post-clean
          4. default — основной жизненный цикл, содержащий следующие фазы:
            1. validate — выполняется проверка, является ли структура проекта полной и правильной.
            2. generate-sources
            3. process-sources
            4. generate-resources
            5. process-resources
            6. compile — компилируются исходные тексты.
            7. process-test-sources
            8. process-test-resources
            9. test-compile
            10. test — собранный код тестируется заранее подготовленным набором тестов.
            11. package — упаковка откомпилированных классов и прочих ресурсов. Например, в JAR-файл.
            12. integration-test — программное обеспечение в целом или его крупные модули подвергаются интеграционному тестированию. Проверяется взаимодействие между составными частями программного продукта.
            13. install — установка программного обеспечения в локальный Maven-репозиторий, чтобы сделать его доступным для других проектов текущего пользователя.
            14. deploy — стабильная версия программного обеспечения распространяется на удаленный Maven-репозиторий, чтобы сделать его доступным для других пользователей.
            15. site — жизненный цикл генерации проектной документации. Состоит из фаз:
              1. pre-site
              2. site
              3. post-site
              4. site-deploy

              Стандартные жизненные циклы могут быть дополнены функционалом с помощью Maven-плагинов. Плагины позволяют вставлять в стандартный цикл новые шаги (например, распределение на сервер приложений) или расширять существующие шаги.

              Архитектура [ править | править код ]

              Maven базируется на plugin-архитектуре, которая позволяет применять плагины для различных задач (англ. compile, test, build, deploy, checkstyle, pmd, scp-transfer ) для данного проекта, без необходимости их в явном виде инсталлировать. Это возможно за счет того, что информация поступает плагину через стандартный вход, а результаты пишутся в его стандартный выход. Теоретически, это позволяет кому угодно писать плагины для взаимодействия со средствами построения проекта (компиляторы, средства тестирования, и так далее) для любого другого языка. В реальности, поддержка других языков кроме Java сейчас минимальна. Существует плагин для .NET-фреймворка [18] , а также плагины для C/C++ [19] [20] .

              Количество доступных плагинов в настоящее время очень велико и включает, в том числе, плагины, позволяющие непосредственно из Maven запускать web-приложение для тестирования его в браузере; плагины, позволяющие тестировать или создавать банки данных; плагины, позволяющие генерировать Web Services. Задачей разработчика в такой ситуации является найти и применить наиболее подходящий набор плагинов.

              Читайте также:  Фон тетрадный лист в клетку для фотошопа

              Плагин обеспечивает достижение ряда целей с помощью следующего синтаксиса:

              Например, Java-проект может быть скомпилирован плагином-компилятором [21] путём выполнения команды mvn compiler:compile .

              Существуют Maven-плагины для построения, тестирования, контроля исходного текста, запуска web-сервера, генерации Eclipse-проектных файлов и множество других. [22] Плагины перечисляются и конфигурируются в секции

              файла pom.xml. Некоторая базовая группа плагинов включается в каждый проект по умолчанию.

              Зависимости [ править | править код ]

              В файле pom.xml задаются зависимости, которые имеет управляемый с помощью Maven проект. Менеджер зависимостей основан на нескольких основных принципах:

              • Репозитории. Maven ищет необходимые файлы в локальных каталогах или в локальном maven-репозитории. Если зависимость не может быть локально разрешена, Maven подключается к указанному maven-репозиторию в сети и копирует в локальный репозиторий. По умолчанию Maven использует Maven Central Repository [23] , но разработчик может конфигурировать и другие публичные Maven-репозитории, такие, как Apache, Ibiblio, Codehaus или Java.Net.
              • Транзитивные зависимости. Необходимые библиотеки подгружаются в проект автоматически. При разрешении конфликта версий используется принцип «ближайшей» зависимости, то есть выбирается зависимость, путь к которой через список зависимых проектов является наиболее коротким.
              • Исключение зависимостей. Файл описания проекта предусматривает возможность исключить зависимость в случае обнаружения цикличности или отсутствия необходимости в определённой библиотеке.
              • Поиск зависимостей. Поиск зависимостей (open-source-библиотек и модулей) ведётся по их координатам (group >[24] . Например, по поисковому признаку «pop3» поисковая машина предоставляет результат с group >[25] .

              Область распространения зависимости позволяет включать зависимости только на определённую стадию построения проекта. Существует 6 возможных областей [26] :

              1. compile. Область по умолчанию. Зависимость доступна во всех путях поиска классов в проекте. Распространяется на зависимые проекты.
              2. provided. Область аналогична compile, за исключением того, что JDK или контейнер сам предоставит зависимость во время выполнения программы.
              3. runtime. Зависимость не нужна для компиляции, но нужна для выполнения.
              4. test. Зависимость не нужна для нормальной работы приложения, а нужна только для компиляции и запуска тестов.
              5. system. Область аналогична provided за исключением того, что содержащий зависимость JAR указывается явно. Артефакт не ищется в репозитории.
              6. import (начиная с версии Maven 2.0.9) используется только с зависимостью типа pom в секции . Зависимости текущего POM заменяются на зависимости из указанного POM.

              Приведение проекта к виду Maven [ править | править код ]

              Проект, поддерживающийся с помощью Maven, должен удовлетворять некоторым условиям для возможности его чтения утилитой, последующего анализа и возможности сборки. Это накладывает некоторые ограничения на структуру каталогов и требует дополнительных действий, если проект изначально имеет отличную структуру. [27]

              Для того, чтобы Maven распознал проект, как подлежащий обработке, он должен содержать установленную структуру каталогов. Все файлы с исходным кодом должны находиться по относительному пути «srcmainjava» [16] .

              Файл конфигурации web-проекта web.xml должен находиться в каталоге «srcmainwebappWEB-INF» [16] .

              Файл конфигурации Maven-проекта pom.xml должен находиться в корневом каталоге проекта. В нём согласно его предназначению могут быть указаны удаленный репозиторий, плагины для создания архивов, плагин компилятора и прочее. Для web-проекта также необходимо добавлять дополнительные зависимости, как например javaee.jar.

              Таким образом, выходной файл конфигурации веб-проекта, согласованный с Maven, выглядит следующим образом:

              После выполнения всех указанных требований Maven-проект готов для выполнения фаз жизненного цикла, таких, как компиляция, сборка архива и генерация документации [28] .

              Пример выходного лога сообщений при выполнении команды mvn war:war :

              Взаимодействие со средами разработки [ править | править код ]

              Для некоторых интегрированных сред разработки Maven содержит плагины, позволяющие управлять жизненным циклом, выполняя команды при помощи интерфейса >[29]

              Эти плагины обеспечивают также возможность удобно редактировать POM или использовать POM для полного описания зависимостей проекта для нужд используемого IDE.

              • Статьи, 25 февраля 2019 в 14:51
              • Сергей Штукатуров

              Maven — инструмент для автоматизации сборки проектов. С ним работают в основном Java-разработчики, хотя есть плагины для интеграции с C/C++, Ruby, Scala, PHP и другими языками. В статье будут рассмотрены особенности и область применения Maven, описан процесс установки и начала работы, а также разобрана структура файла описания проекта.

              Назначение и особенности

              Собрать на Java проект уровня «Hello, world!» можно и с помощью командной строки. Но чем сложнее разрабатываемое ПО и чем больше оно использует сторонних библиотек и ресурсов, тем сложнее будет команда для сборки. Maven разработан для облегчения этой работы.

              Одна из главных особенностей фреймворка — декларативное описание проекта. Это значит, что разработчику не нужно уделять внимание каждому аспекту сборки — все необходимые параметры настроены по умолчанию. Изменения нужно вносить лишь в том объёме, в котором программист хочет отклониться от стандартных настроек.

              Ещё одно достоинство проекта — гибкое управление зависимостями. Maven умеет подгружать в свой локальный репозиторий сторонние библиотеки, выбирать необходимую версию пакета, обрабатывать транзитивные зависимости.

              19 ноября 2019 – 10 января 2020, Гусев и онлайн, беcплатно

              Разработчики также подчёркивают независимость фреймворка от ОС. При работе из командной строки параметры зависят от платформы, но Maven позволяет не обращать внимания на этот аспект.

              При необходимости систему сборки можно настроить под собственные нужды, используя готовые плагины и архетипы. А если ничего подходящего не нашлось — можно написать свои.

              В этой статье мы будем работать с Maven с помощью командной строки, однако этот фреймворк также интегрирован в Eclipse, IntelliJ IDEA, NetBeans и другие IDE.

              Установка, настройка и создание стандартного проекта

              Скачать Maven можно с официальной страницы проекта. Там же вас познакомят с минимальными требованиями — на машине должен быть установлен JDK, а также потребуется свободное место на диске, около 500 мегабайт. Это место нужно не для самой установки, оно будет использовано для создания локального репозитория.

              На странице скачивания вы найдёте несколько разных архивов, для первого раза лучше использовать готовые бинарники. Исходники потребуются, если захочется всё сломать покопаться в Maven.

              Архив можно распаковать в любое удобное место. После этого нужно добавить путь к папке bin из распакованного архива в переменную среды PATH . В Windows нужно зайти в настройки параметров системы (вызывается комбинацией клавиш Win+Pause или щелчком правой кнопкой мыши по ярлыку «Мой / Этот компьютер» -> «Свойства»), и выбрать пункт «Дополнительные параметры системы». В правом нижнем углу нажмите кнопку «Переменные среды». Выберите переменную PATH , нажмите «Изменить», в открывшемся окне — «Создать» и добавьте путь. Обратите внимание, путь должен вести именно к папке bin .

              В ОС на основе Unix переменную среды можно добавить консольной командной:

              Проверить, всё ли сделано правильно, можно с помощью консольной команды mvn -v . Вы должны увидеть что-то подобное:

              Создаём папку для нового проекта и переходим в неё. Далее создаём новый проект. Для этого в консоли выполните команду:

              Выглядит довольно сложно, поэтому разберём её по порядку.

              archetype : generate это так называемая цель. Она указывает Maven, что нужно создать проект из архетипа. Дальше с помощью -D мы указываем определённые параметры генерации.

              • groupId = com . mycompany . app указывает на разработчика ПО, там вы можете указать доменное имя своей компании.
              • artifactId = my — app — название проекта. Maven оперирует так называемыми артефактами. Это приложения, плагины, архетипы и другие проекты. И ваша разработка также будет считаться артефактом.
              • archetypeArtifactId = maven — archetype — quickstart указывает, какой архетип использовать в качестве шаблона для создания приложения. Как видите, это тоже артефакт. Указанный архетип создаст простой проект, сгенерирует структуру каталогов и даже заботливо положит в папку исходников программу «Hello, world!», чтобы вам не пришлось самому писать её в двухсотый раз.
              • archetypeVersion = 1.4 указывает на версию артефакта «архетип».
              • interactiveMode = false отключает создание проекта в интерактивном режиме. Вы можете запустить цель archetype : generate без параметров, и Maven предложит установить параметры в процессе генерации. В данном случае нам это не нужно. Кстати, отключить интерактивный режим можно параметром -B . Полный список параметров для mvn можно получить по команде mvn -h .
              Читайте также:  Happy glass 254 уровень

              Выполнив команду, Maven сгенерирует следующую структуру проекта:

              Исходники нашего проекта будут лежать в папке src/main/java (и сейчас там уже есть автоматически сгенерированный файл), но нам сейчас интереснее файл pom.xml в корневом каталоге. Это и есть тот самый файл описания проекта, на основе которого осуществляются все операции Maven. Он написан на языке POM, входящим в семейство XML:

              Разберёмся, что всё это значит.

              Что значат теги в pom.xml

              Тег project является базовым и содержит всю информацию о проекте. В заголовке указана информация, необходимая Maven для понимания файла pom.xml . Тег modelVersion указывает на текущую версию POM. Эти два тега обычно генерируются автоматически, менять их не нужно.

              Затем идёт информация, формирующая уникальный идентификатор проекта, теги groupId и artifactId . Её мы задавали выше при генерации из архетипа. Тег version тоже входит в эту группу. Он обычно генерируется и обновляется автоматически. После номера версии идёт суффикс -SNAPSHOT . Это означает, что проект находится в стадии разработки. В процессе выпуска ПО фреймворк уберёт этот суффикс, а если разработка продолжится — автоматически увеличит номер версии. Вместе эти три тега позволяют однозначно идентифицировать артефакт.

              name содержит отображаемое имя артефакта, а url — ссылку на сайт. Поскольку сайт не задан при генерации, pom.xml содержит напоминание об этом в виде комментария. Кроме того, можно добавить краткое описание в description . Эти три тега зачастую используются при формировании документации.

              Дальше мы видим блок properties . Здесь указаны особые настройки, такие как кодировка файла и используемая версия компилятора Java. Без этого блока можно обойтись, положившись на настройки по умолчанию.

              Следом идёт очень важный блок dependencies . В нём описываются все используемые в проекте зависимости. Каждую необходимо выделить тегом dependency и указать уникальные идентификационные данные: groupId , artifactId и version . Maven сам подгрузит транзитивные зависимости. Кроме того, с помощью тега scope можно указать этапы, на которых будет использован артефакт. Сейчас в pom.xml всего одна зависимость — артефакт JUnit, библиотека для модульного тестирования на Java, которая будет использоваться только на стадии тестирования.

              Кстати, это хороший повод поговорить о жизненном цикле проекта. Maven выполняет сборку последовательными фазами. Приводим их названия на английском, так как они используются в качестве команд.

              1. Проверка — validate . Фреймворк проверяет, корректен ли проект и предоставлена ли вся необходимая для сборки информация.
              2. Компиляция — compile . Maven компилирует исходники проекта.
              3. Тест — test . Проверка скомпилированных файлов. В нашем случае будет использована библиотека JUnit.
              4. Сборка проекта — package . По умолчанию осуществляется в формате JAR. Этот параметр можно изменить, добавив в project тег packaging .
              5. Интеграционное тестирование — integration-test . Maven обрабатывает и при необходимости распаковывает пакет в среду, где будут выполняться интеграционные тесты.
              6. Верификация — verify . Артефакт проверяется на соответствие критериям качества.
              7. Инсталляция — install . Артефакт попадает в локальный репозиторий. Теперь его можно использовать в качестве зависимости.
              8. Размещение проекта в удалённом репозитории — deploy , — финальная стадия работы.

              Эти фазы упорядочены и выполняются поочерёдно. Если необходимо собрать проект, система последовательно проведёт оценку, компиляцию и тестирование, и только после этого сборку. Помимо этого есть две фазы, выполняющиеся отдельно, только прямой командой. Это очистка — clean , удаляющая предыдущие сборки, и создание документации для сайта — site .

              Закончим рассмотрение pom.xml секцией build . Она не является обязательной, в данном pom.xml в неё включены плагины из архетипа, однако можно обойтись и без них. Плагинов для Maven тысячи, освоившись с применением фреймворка вы сможете сами подобрать себе необходимые.

              В проектах чуть серьёзнее, чем вычисление факториала, приходится использовать внешние ресурсы. Maven способен автоматически обрабатывать файлы ресурсов и размещать их в сборке проекта. Для этого их нужно разместить в папке src/main/resources . Файлы будут упакованы с сохранением внутренней структуры каталогов. Если же по какой-то причине нужно переопределить каталог, используйте вложенные теги resources , resource , directory в секции build :

              Итак, с файлом описания мы разобрались. Попробуем собрать проект. Для этого перейдём в корневую папку и выполним команду нужной фазы, mvn package . Получим отчёт о сборке:

              Теперь в корневом каталоге проекта вы обнаружите папку target, а в ней готовый файл my-app-1.0-SNAPSHOT.jar .

              Запустите команду java — cp target / my — app — 1.0 — SNAPSHOT . jar com . mycompany . app . App — вы должны увидеть «Hello World!».

              Поздравляем! Вы собрали проект с помощью Maven. Для более детального изучения инструмента советуем обратить внимание на эти книги и материалы.

              На просторах сети вообще и хабра в частности мне доселось видеть не один топик посвящённый Maven. И везде, где было обсуждение, возникали вопросы вида:

              • Что даёт его использование в проекте типа X?
              • Чем он лучше Ant/Make/sh?
              • А что делать если я хочу использовать в проекте antlr/JAX-WS/XDoclet?

              Я полагаю, что все эти вопросы происходят из незнания что на свете есть гугл недостаточного понимания что такое Maven и какой подход к решению задач build management он предлагает. Что в свою очередь растёт из недостаточного внимания, которое авторы статей уделяют идеям стоящим за xml-файлами и завораживающими консольными командами.

              Мне очень выжным является понимание того, что когда говорят Maven подразумевают 3 достаточно слабо связанные вещи:

              • POM. Project object model. Модель проекта — в ней описано из чего проект состоит и как устроен его жизненный цикл.
              • Репозитории артефактов. Места хранения продуктов сборки программных модулей вместе с метаданными.
              • Утилиту mvn и плагины к ней. Собственно инструмент сборки проектов управления жизненным циклом модулей.

              Давайте рассмотрим каждую в отдельности, чтобы понять как их можно использовать вместе.

              Это общая модель проектов. В ней описываются такие общие характеристики как имя, версия, авторы и их контактная информация, VCS проекта и вообще связанные с ним сетевые ресурсы, тип проекта (например библиотека или web-модуль, в оригинальной терминологии называется packaging, хотя влияет не только на тип получаемого артефакта), связи с другими проектами, используемые при сборке плагины и описания способа их задействования. Мне кажутся особенно важными два компонента этой модели.

              Связи с другими модулями

              POM допускает три типа связей с другими модулями: зависимость, включение и наследование.

              Зависимость, эта связь говорит, что для некоторых фаз жизненного цикла нашего модуля, требуются некоторые артефакты модулей-зависимостей (абстрактно получилось — аж самому страшно). Что конкретно и на какой фазе жизненного цикла требуется определяется так называемой областью действия зависимости. Maven понимает несколько предопределённых областей действия и позволяет добавлять свои. В качестве примера ограничусь одной областью действия: compile — она говорит, что бинарные сборки зависимости требуются на этапе компиляции, выполнения тестов и во время выполнения.

              Включение — говорит, что связанный модуль является неотъемлемой частью нашего модуля. Для прохождения нашим модулем некоторой фазы жизненного цикла, входящий в него также должен пройти эту фазу. Классический пример enterprise-модуль, включающий в себя web-модуль, пакет с EJB и общую библиотеку. Очевидно, что его сборка требует сборки каждого из включаемых модулей.

              Читайте также:  Acrobat reader dc как установить русский язык

              Наследование. Такая связь подразумевает перенос на наследника части модели предка. Правила переноса несколько запутаны, но в основном действует принцип — значение параметра модели предка становится умолчанием для модели потомка. Пример из моей практики: был создан модуль, устанавливающий версию JDK для компиляции проектов, внутренние репозитарии для результатов, набор правил для поверки соответствия исходников стандарту кодирования, он должен был использоваться (а кое-где и действительно использовался 😉 ) как родитель для всех разрабатываемых в рамках проекта модулей.

              Описание используемых при сборке плагинов

              Описание состоит из имени задействуемого плагина, некоторых его настроек(они определяются плагинами индивидуально), и собственно выполняемых им целей на каждой из фаз жизненного цикла(подробное описание идей, стоящих за этими терминами см. ниже).

              Этот элемент несколько чужд общей идеи POM — он несёт не декларативное описание модуля, а инструкции по его сборке конкретным инструментом.

              Итоги
              1. POM — эта общая, унифицированая модель описания программных модулей.
              2. Она поддерживает хранение не только аттрибутов отдельных модулей но и высокоуровневых связей между ними.
              3. Также она несёт информацию об инструментах, необходимых для поддержки жизненного цикла модуля.

              Репозитории артефактов

              Репозитории артефактов являются выделенными хранилищами результатов сборки, устроенными так, чтобы упростить поиск нужного артефакта (по имени, версии, типу артефакта). Они позволяют группе разработчиков пользоваться результатами работы друг друга без необходимости иметь копии исходных кодов их модулей и выполнять сборку дерева зависимостей с 0. Maven-совместимые репозитарии стали стандартом де факто публикации результатов различных открытых проектов.

              Нужно заметить, что pom-файлы, содержащие модель проекта, также являются артефактами и могут хранится в репозитариях вместе со всеми (на самом деле по крайней мере урезанные их версии, содержащие только идентификацию модуля и зависимости, хранятся всегда). Таким образом репозитарий является в том числе источником информации (как миннимум достаточной для дистрибуции) о хранимых в нём модулях.

              Итак, какие бонусы они нам дают:

              1. Структурированное хранение артефактов, их каталогизация.
              2. Повторное использование артефактов.

              Утилита управления жизненным циклом

              Название получилось достаточно пафосное, однако оно вполне соответствует высокой миссии и сложности предмета.

              Прежде чем погрузиться в её функции, необходимо немного познакомится с теорией организации жизненного цикла модуля в Maven. Жизненным циклом называется вся совокупность операций над модулем от инициализации сборки до развёртывания. В процессе прохождения жизненного цикла выполняются определённые операции над модулем, формируются некоторые артефакты. Жизненный цикл разделён на фазы. Каждая фаза подразумевает перевод модуля в новое состояние в результате её прохождения и появление новых артефактов. Каждая предыдущая фаза подготовливает основу для последующей. Список фаз является по сути частью POM, но глобальной, общей для всех модулей. Поный список приводить бессмысленно, но для примера приведу несколько фаз (достаточно интуитивно названных, на мой взгляд 🙂 ) в порядке их следования: compile,… test,… deploy.

              В рамках каждой фазы выполняется некоторый набор целей в зависимости от модели конкретного модуля. Цель является конкретной операцией над исходными кодами и/или артефактами.

              Теперь к самой утилите. Она отвечает за реализацию жизненного цикла на основании модели проекта. Состоит из двух основных компонентов:

              1. Во-первых из совсем маленького ядра, в котором описаны (захардкожены, как говорит простой народ) базовые принципы устройства проектов, цели по умолчанию для фаз стандартных типов проектов, рабочая среда для плагинов (интерфейсы доступа к моделям, репозитариям, ФС, настройкам и т.п.).
              2. Во-вторых из плагинов. Они собственно содержат код, выполняющий цели. Практически вся внешняя функциональность mvn реализуется ими. Именно они генерируют, компилируют, тестируют, пакуют и т.д. и т.п.

              Общение с этой утилитой построено предельно просто: вы говорите до какой кондиции фазы нужно довести клиента модуль и она это делает. Вся сложность формулировки и выполнения задач по достижению цели остаётся на совести разработчиков плагинов (ну хорошо, немного остаётся на разработчика модели). Например говорим compile и нам компилируют, причём не только то, что вылезло из VCS но и генерируют необходимое например wsimport’ом и результаты тоже компилируют.

              Также можно попросить выполнить отдельную задачу конкретного плагина. Например есть плагин для генерации Eclipse-проектов, задача «сгенерировать проект» которого по умолчанию не привязывается ни к одной фазе, а вызывается заинтересованными лицами вручную.

              Ещё одной крайне интересной функцией mvn является создание заготовки проекта на основе архетипа. Архетип — обобщённый шаблон проекта, традиционно концентрирующийся на его структуре и используемых плагинах. Например есть стандартные архетипы java-библиотеки, web-модуля, и нестандартные, например grails приложение. Важно понимать отличие архетипа от типа проекта. Архетип — только шаблон начальной структуры и отдельных частей проекта, после создания проекта никакой информации о его архетипе не остаётся. Тип проекта — наоборот, часть модели, которая используется на протяжении всего жизненного цикла.

              Что получается в сумме

              Итак, мы выделили три столпа Maven. Что-же они дают нам вместе?

              • Концентрирование информации о модуле в одном месте и в одном формате. Не всё тут гладко, но многие IDE могут импортировать проекты из POM, большинство серверов автокомпиляции (continuous integration, как говорят адепты XP) также могут использовать их добавлении проекта.
              • Единая система идентификации модулей. Очень просто и очень важно. У нас нет теперь обозначений типа багфикс-ветка нашего-супер-проекта, собранная в 23 часа в прошлую субботу.
              • Один инструмент. Хотя это, прямо скажем, не уникальная фича Maven. Не удержусь и повторю прописную истину: проект должен собираться стандартными и переносимыми средствами. Сборка любимой IDE Первого Разработчика Проекта — путь в ад.
              • Автоматическое управление зависимостями. Связывание исходного кода проекта с бинарными сборками чего-то, очень невесёлая практика. Особо надо отметить трудности с поддержкой репозитариев исходников (сколько магнитных лент занимает бэкап вашего svn?)) ). Изобретения велосипеда в виде своих репозитариев или скриптов подтаскивающих исходнки зависимостей тоже не лучшее решение в эпоху, когда космические корабли бороздят просторы вселенной.
              • Повторное использование решений, связанных с устройством и процедурой сборки проектов. Благодаря наследованию и включению проектов мы можем многократно использовать однажды разработанные модели проектов, настройки, связанные с инфраструктурой и инструментарием принятыми в нашей компании. Использование архетипов позволяет автоматизировать этап создания новых проектов, съэкономить время на подготовке структуры проекта и минимизировать ошибки в использовании внешних моделей.
              • Готовое средство для управления результатами работы и простота их последующего использования. Настраиваем инфраструктуру подобающим образом и каждый билд оседает в нужном месте и доступен для последующего использования. Нужно проверить работоспособность разных компоновок версий/веток модулей большого проекта? Просто правим зависимости в POM.

              Заключение

              Что-то я местами отклонился от центрального вопроса и вплотную занялся вопросом «как», ну да ладно…

              Из всей информации, приведённой выше, можно сделать простой, но почему-то весьма редкий вывод. Maven — не утилита для сборки Java-приложений. Maven — фреймворк для автоматизации большого спектра задач при поддержке проекта. Он никак не связан с языком и платформой, более того он совершенно не обязан что-либо собирать. Вы с помощью описания моделей или написания плагинов превращаете его в тот или иной инструмент. Да, принятая в нём по модель по умолчанию — сборка Java-модулей, но это лишь умолчания…

              Надеюсь, что после прочтения топика каждый может уверенно ответить на вопросы, приведённые в начале 😉

              Рекомендуем к прочтению

              Добавить комментарий

              Ваш адрес email не будет опубликован.