21-06-2023
Тип | |
---|---|
Разработчик | |
Написана на | |
Операционная система | |
Последняя версия | |
Лицензия | |
Сайт |
maven.apache.org |
Apache Maven — фреймворк для автоматизации сборки проектов, специфицированных на XML-языке POM[2] (англ. Project Object Model).
Слово maven происходит из языка Идиш и означает примерно «собиратель знания».[3]
Maven, в отличие от другого сборщика проектов Apache Ant, обеспечивает декларативную, а не императивную сборку проекта. То есть, в файлах проекта pom.xml содержится его декларативное описание, а не отдельные команды. Все задачи по обработке файлов Maven выполняет через плагины.
Содержание |
Информация для программного проекта, поддерживаемого Мавеном, содержится в 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]
Большая часть функциональности 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). Если бы 'cleaning' было частью обычного жизненного цикла, проект подвергался бы чистке при каждом построении, что нежелательно.
Стандартные жизненные циклы могут быть существенно дополнены 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). Эти координаты могут быть определены с помощью специальных поисковых машин, например:[10]. Введя в такой машине, например, поисковый признак «pop3», вы получите, среди прочих, и строку с groupeId="com.sun.mail" и artefactId="pop3", что выглядит очень прилично. Чаще же результаты будут менее вразумительны и только опытным путем вы сможете определить, что заказали именно тот jar-файл, который хотели.
Принадлежащие фирме и расположенные в её интранете репозитории реализуются обычно с помощью таких программных средств, как Apache Archiva, Nexus, Artifactory, Proximity, Codehaus Maven Proxy или Dead Simple Maven Proxy.
Для самых распространенных интегрированных сред разработки (IDE) имеются плагины, позволяющие удобно управлять Maven-ом. Их список включает:
Эти плагины обеспечивают также возможность удобно редактировать POM или использовать POM для полного описания зависимостей проекта для нужд используемого IDE.
Maven базируется на maven-native и maven-nar
Количество плагинов стало сейчас очень впечатляющим: от плагинов, позволяющих прямо из Maven-а стартовать web-приложение, чтобы тестировать его в браузере, через те, которые позволяют тестировать или создавать банки данных, и до таких, которые генерируют Web Services. Задача разработчика ограничивается нередко только тем, чтобы выявить и применить необходимый плагин.
Проект, в котором предполагается использовать Maven, создается обычно сразу, как Maven-проект. Это создает определенные трудности, если проект изначально имеет другую структуру — например, если это web-проект.
Разработчик, называющий себя mkyoung, предлагает следующую процедуру преобразования web-проекта к Maven-проекту[12] (англ.)
Внесите в «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-ом, описание плагинов сохранено.)
<dependencies> <dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>6.0</version> </dependency> </dependencies>
Maven скачает все описанные вами зависимости в свой локальный репозиторий и вы увидите следующую картинку:
E:\workspace\servletdemo>mvn compile [INFO] Scanning for projects... ....... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------
mvn eclipse:eclipse -Dwtpversion=2.0
После этого вы можете импортировать этот проект в вашу Eclipse IDE
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] -----------------------------------------------
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-го года.[13]
Maven 1.x не разрабатывается дальше и ограничивается поддержкой пользователей и устранением ошибок.[14]
Разработка Maven 3.0 началась в 2008 г.. После восьми альфа-релизов, первая бета-версия Maven 3.0 была опубликована в октябре 2010 г. Особенное внимание было уделено её обратной совместимости с Maven 2. Для большинства проектов переход от 2-й к 3-й версии не требует никаких изменений.
Дальнейшая разработка Maven-а происходит в следующих подпроектах:
Системы автоматизации сборки | |
---|---|
Системы автоматизации сборки | Make · Premake · CMake · SCons · Apache Ant · Apache Maven · NAnt · Buildout · MSBuild · Waf · Rake · Autotools |
Это заготовка статьи о программном обеспечении. Вы можете помочь проекту, исправив и дополнив её. |
Apache Maven.