Apache Maven

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Apache Maven
Maven logo.svg
Тип

Автоматизация сборки

Разработчик

Apache Software Foundation

Написана на

Java[1]

Операционная система

Кроссплатформенное программное обеспечение

Последняя версия

3.2.3 (17 августа 2014)

Лицензия

Apache 2.0 licence

Сайт

maven.apache.org

Apache Maven — фреймворк для автоматизации сборки проектов, специфицированных на XML-языке POM[2] (англ. Project Object Model).

Слово maven происходит из языка идиш и означает примерно «собиратель знания»[3].

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

Файл pom.xml: Проект-Объектная Модель[править | править вики-текст]

Информация для программного проекта, поддерживаемого Мавеном, содержится в XML-файле с именем pom.xml (от Project Object Model). При исполнении Мавен проверяет прежде всего, содержит ли этот файл все необходимые данные и все ли данные синтаксически правильно записаны.

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

<project>
  <!-- версия модели для POM-ов Maven 2.x всегда 4.0.0 -->
  <modelVersion>4.0.0</modelVersion>
 
  <!-- координаты проекта, то есть набор значений, который
       позволяет однозначно идентифицировать этот проект -->
 
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>
 
  <!-- зависимости от библиотек -->
 
  <dependencies>
    <dependency>
 
      <!-- координаты необходимой библиотеки -->
 
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
 
      <!-- эта библиотека используется только для запуска и компилирования тестов -->
 
      <scope>test</scope>
 
    </dependency>
  </dependencies>
</project>

Конфигурация включает имя проекта, его собственника и его зависимости от других проектов. Возможно, также, конфигурировать индивидуальные фазы процесса построения проекта (build process), реализованные плагинами. Например, можно конфигурировать плагин компилятора так, что он будет использовать определённую версию Java, или специфицировать упаковку проекта даже в случае негативного результата прохождения некоторых тестов.

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

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

Мавен поддерживает принцип «соглашения прежде конфигурации» (Convention over Configuration). Поскольку проект придерживается избранной системы соглашений, постольку отпадает необходимость специфицировать их, что сильно упрощает pom.xml. Однако, почти все стандарты, на которые опирается Maven, могут быть изменены индивидуальной конфигурацией.

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

Стандартная структура каталогов — одна из реализаций этого принципа. Поскольку проект её придерживается — отпадает необходимость специфицировать пути к файлам, что сильно упрощает pom.xml.

Следующая структура показывает важнейшие каталоги.[5]

  • Корневой каталог проекта: файл pom.xml и все дальнейшие подкаталоги
    • src: все исходные файлы
      • src/main: исходные файлы собственно для продукта
        • src/main/java: Java-исходный текст
        • src/main/resources: другие файлы, которые используются при компиляции или исполнении, например Properties-файлы
      • src/test: исходные файлы, необходимые для организации автоматического тестирования
        • src/test/java: JUnit-тест-задания для автоматического тестирования
    • target: все создаваемые в процессе работы Мавена файлы
      • target/classes: компилированные Java-классы

Стандартный набор плагинов[править | править вики-текст]

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

 mvn [имя плагина]:[имя цели]

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

 mvn compiler:compile

Существуют Maven-плагины для построения, тестирования, контроля исходного текста, запуска web-сервера, генерации Eclipse-проектных файлов и множество других.[7] Плагины перечисляются и конфигурируются в <plugins>-секции файла pom.xml. Некоторая базовая группа плагинов включается в каждый проект по умолчанию. Они имеют гибкую конфигурацию по умолчанию.

Однако, было бы слишком громоздко вручную описывать построение, тестирование и упаковку проекта:

 mvn compiler:compile
 mvn surefire:test
 mvn jar:jar

Концепция жизненного цикла проекта решает эту задачу более удобно.

Стандартный жизненный цикл[править | править вики-текст]

Жизненный цикл проекта — это список поименованных фаз, определяющий порядок действий при его построении. Maven использует по умолчанию следующий жизненный цикл:[8]

  1. Создание темплейта и обработка ресурсов (archetype): На этой фазе разрешаются и, при необходимости, скачиваются из интернета зависимости.
  2. Компиляция (compile)
  3. Обработка тестовых ресурсов. (Например — скачивается из интернета JUnit-пакет).
  4. Компиляция тестов. (Тестирующие классы не передаются конечным пользователям.)
  5. Тестирование (test)
  6. Упаковка (package). Обычно речь идёт о создании JAR- или WAR-файла.
  7. Инсталляция проекта в локальном Maven-репозитории (install). Теперь он доступен как модуль для других локальных проектов.
  8. Инсталляция в удаленном Maven-репозитории (deploy). Теперь стабильная версия проекта доступна широкому кругу разработчиков.

Maven имеет также стандартный жизненный цикл для чистки (cleaning) и для генерации его страницы (site). Если бы 'clean' было частью обычного жизненного цикла, проект подвергался бы чистке при каждом построении, что нежелательно.

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

Функционирование[править | править вики-текст]

Если структура проекта соответствует стандартам Maven, то команда:

 mvn package

откомпилирует все Java-файлы, запустит предусмотренные тесты, и упакует поставляемый программный код и ресурсы в target/my-app-1.0.jar (в предположении, что artifactId было определено как 'my-app' и версия — как 1.0.)

Используя собственно Maven, пользователь обеспечивает только конфигурацию своего проекта, так как реальную работу по компиляции проекта, чистке целевых каталогов, выполнению элементных тестов, генерации API-документов и т. д. выполняют конфигурируемые плагины. В общем случае, пользователь не должен сам писать плагины. Сравните это с Ant и make, где для выполнения указанных задач пишутся императивные процедуры.

Разрешение зависимостей, центральный репозиторий[править | править вики-текст]

В файле pom.xml задаются зависимости, которые имеет управляемый Maven-ом пакет от других программных пакетов. Эти зависимости Maven разрешает, то есть, сначала он проверяет, находятся ли необходимые файлы в локальных каталогах или в локальном Maven-репозитории. Если зависимость не может быть локально разрешена, Maven пытается связаться с конфигурированным для него Maven-репозиторием в интранете или в интернете и копировать необходимые данные оттуда в локальный репозиторий. По умолчанию Maven использует Maven Central Repository[9], но разработчик может конфигурировать и другие публичные Maven-репозитории, такие, как Apache, Ibiblio, Codehaus или Java.Net.

Поиск зависимостей (open-source-библиотек и модулей) ведётся по их координатам (groupeId, artefactId и version). Эти координаты могут быть определены с помощью специальных поисковых машин, например, Maven search engine[10]. Введя в такой машине, например, поисковый признак «pop3», вы получите, среди прочих, и строку с groupeId="com.sun.mail" и artefactId="pop3", что выглядит очень прилично. Чаще же результаты будут менее вразумительны и только опытным путем вы сможете определить, что заказали именно тот jar-файл, который хотели.

Принадлежащие фирме и расположенные в её интранете репозитории обычно реализуются с помощью менеджеров репозиториев Maven (Maven Repository Manager), таких как Apache Archiva, Nexus (ранее Proximity), Artifactory, Codehaus Maven Proxy или Dead Simple Maven Proxy[11].

Поддерживаемые IDE[править | править вики-текст]

Для самых распространённых интегрированных сред разработки (IDE) имеются плагины, позволяющие удобно управлять Maven-ом. Их список включает:

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

Дизайн[править | править вики-текст]

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

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

Web-проекты[править | править вики-текст]

Проект, в котором предполагается использовать Maven, создается обычно сразу, как Maven-проект. Это создает определенные трудности, если проект изначально имеет другую структуру — например, если это web-проект.

Разработчик, называющий себя mkyoung[неавторитетный источник? 385 дней], предлагает следующую процедуру преобразования web-проекта к Maven-проекту[14] (англ.)

  • Создайте Maven-структуру каталогов (см. выше)
  • Перенесите все Java-исходные файлы в папку «\src\main\java».
  • Перенесите «web.xml» файл из папки «WebContent\WEB-INF» в папку «\src\main\webapp\WEB-INF»
  • Создайте новый «pom.xml» файл, поместите его в корневой каталог проекта

Внесите в «pom.xml» параметры проекта, добавьте удаленный репозиторий, плагин для создания WAR и плагин компилятора.

После этого ваш pom.xml может выглядеть так:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mkyong</groupId>
  <artifactId>servletdemo</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>servletdemo</name>
  <url>http://maven.apache.org</url>
 
  <repositories>
    <repository>
      <id>java.net</id>
      <url>http://download.java.net/maven/2</url>
    </repository>
  </repositories>
 
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <webResources>
            <resource>
              <directory>${basedir}/src/main/java</directory>
              <targetPath>WEB-INF/classes</targetPath>
              <includes>
                <include>**/*.properties</include>
                <include>**/*.xml</include>
                <include>**/*.css</include>
                <include>**/*.html</include>
              </includes>
            </resource>
          </webResources>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

(Описывать плагины в общем-то излишне — они входят в стандартный набор, к тому же — они описаны неправильно: отсутствует указание version. Но поскольку этот пример призван не только показать решение проблемы веб-приложений, но и дать хорошее представление о работе с Maven-ом, описание плагинов сохранено.)

  • Внесите в ваш pom.xml (после «<repositories>») раздел «<dependencies>» (предполагается, что ваше web-приложение использует библиотеку «javaee.jar»):
  <dependencies>
    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>6.0</version>
    </dependency>
  </dependencies>
  • Выполните в консоли команду mvn compile

Maven скачает все описанные вами зависимости в свой локальный репозиторий и вы увидите следующую картинку:

E:\workspace\servletdemo>mvn compile
[INFO] Scanning for projects...
.......
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
  • Почти готово. Теперь преобразуйте ваш Maven-проект так, чтобы его поддерживала Eclipse IDE
mvn eclipse:eclipse -Dwtpversion=2.0

После этого вы можете импортировать этот проект в вашу Eclipse IDE

  • Выполните в консоли команду «mvn war: war»

Maven сгенерирует WAR-файл проекта и поместит его под именем «servletdemo-1.0-SNAPSHOT.war» в папку «target» проекта. В этот файл будут запакованы все библиотеки зависимостей, скомпилированные классы и структура каталогов.

E:\workspace\servletdemo>mvn war:war
[INFO] Scanning for projects...
.......
[INFO] Processing war project
[INFO] Copying webapp resources[E:\workspace\servletdemo]
[INFO] Webapp assembled in[47 msecs]
[INFO] Building war: E:\workspace\servletdemo\target\servletdemo-1.0-SNAPSHOT.war
[INFO] -----------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] -----------------------------------------------
  • Ваш WAR-файл готов к «deployment» — передаче web-серверу для исполнения

Разработка Maven-а[править | править вики-текст]

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

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-го года.[15]

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

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

Действующие подпроекты[править | править вики-текст]

Дальнейшая разработка Maven-а происходит в следующих подпроектах:

  • Maven 1.x и Maven 2.x — старые версии Maven-а.
  • Maven 3 развивает текущую линию продуктов Maven.
  • 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.

Примечания[править | править вики-текст]

См. также[править | править вики-текст]

Ссылки[править | править вики-текст]