Время на прочтение
6 мин
Количество просмотров 528K
После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.
Терминология
Как в любой системе, в Maven, есть свой набор терминов и понятий.
Вся структура проекта описывается в файле pom.xml (POM – Project Object Model), который должен находиться в корневой папке проекта. Ключевым понятием Maven является артефакт — это, по сути, любая библиотека, хранящаяся в репозитории. Это может быть какая-то зависимость или плагин.
Зависимости — это те библиотеки, которые непосредственно используются в вашем проекте для компиляции кода или его тестирования.
Плагины же используются самим Maven’ом при сборке проекта или для каких-то других целей (деплоймент, создание файлов проекта для Eclipse и др.).
В самом начале работы с Maven, пользователь непременно столкнется с таким понятием как архетип. Архетип — это некая стандартная компоновка файлов и каталогов в проектах различного рода (веб, swing-проекты и прочие). Другими словами, Maven знает, как обычно строятся проекты и в соответствии с архетипом создает структуру каталогов.
Как правило, название артефакта состоит из названия группы, собственного названия и версии. К примеру Spring будет иметь вот такое название в среде Maven: org.springframework.spring:2.5.5. Последний домен означает всегда artifactId, все, что перед ним – groupId – хорошо это запомните!
На жизненном цикле останавливаться не буду, так как он хорошо описан в вышеобозначенной статье. А теперь перейдем к практике.
Установка Maven
Последнюю версию всегда можно скачать на странице загрузки на официальном сайте. Просто распаковываем архив в любую директорию. Далее необходимо создать переменную в Path, в которой необходимо указать путь к Maven. Заходим в Win + Pause – Дополнительно – Переменные среды – в верхнем окошке нажимаем Создать, вводим имя M2_HOME и значение допустим “C:\apache-maven-2.2.1”. Далее там же создаем еще одну переменную M2 со значением %M2_HOME%\bin. Так же убеждаемся, что есть переменная JAVA_HOME с путем к JDK. Ее значение должно быть примерно таким «c:\Program Files\Java\jdk1.6.0_10\». И наконец в том же окошке создаем/модифицируем переменную Path, в нее необходимо просто написать %M2%, чтобы наша папочка с исполняемым файлом Maven была видна из командной строки. Теперь необходимо проверить работоспособность нашей установки. Для этого заходим в командную строку и вводим команду
mvn –version
Должна появиться информация о версиях Maven, jre и операционной системе, что-то вроде:
Maven version: 2.2.1 Java version: 1.6.0_10 OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
Maven создаст вам локальный репозиторий в вашей личной папке, например в каталоге C:\Documents and Settings\username\.m2\repository
Все, Maven готов к работе, можно приступать к созданию приложения.
Создание приложения из архетипа
На сайте Maven перечислены наиболее популярные архетипы для приложений, но вы можете легко создать свой или найти более специфичный например здесь.
Итак, допустим нас интересует веб-приложение – находим подходящий архетип, называется он maven-archetype-webapp. В командной строке, в необходимом каталоге выполняем команду Maven:
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp
-DarchetypeArtifactId=maven-archetype-webapp
Теперь мы можем лицезреть довольно наглядную структуру каталогов с говорящими названиями java – здесь будут ваши классы, webapp – здесь размещаются странички веб-приложения, resources – различного рода ресурсы в classpath (файлы конфигурации, например), test – юнит-тесты, соответственно и т.п.
Сборка проекта
Здесь все просто – выполняем команду
mvn package
или
mvn install
в корневом каталоге приложения, там, где находится файл pom.xml. Первая команда скомпилирует ваш проект и поместит его в папку target, а вторая еще и положит его к вам в локальный репозиторий.
Есть полезная функция, наподобие конвеера, то есть можно написать
mvn clean install
и Maven сначала очистит папку target проекта, потом соберет его и положит в репозиторий.
Минимальный набор действий для работы Maven мы изучили, теперь переходим к кастомизации и добавлению зависимостей проекта.
Зависимости и репозитории
Как правило, большинство популярных библиотек находятся в центральном репозитории, поэтому их можно прописывать сразу в раздел dependencies вашего pom-файла. Например чтобы подключить Spring Framework необходимо определить следующую зависимость:
<dependencies>
...
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.5</version>
</dependency>
</dependencies>
Версию хотя и можно не указывать и тогда Maven возьмет последний вариант, но я вам лично советую это делать, потому как у нас неоднократно бывали случаи, что проект просто в один момент переставал собираться или начинал падать в совершенно неожиданных и хорошо оттестированных местах, хотя вроде бы никто ничего не менял.
Специфические вещи обычно не находятся в центральном репозитории и тогда вам придется указать репозиторий производителя вручную. Для примера добавим зависимость JSF-фреймворка ajax-компонентов JBoss RichFaces.
С зависимостями все просто:
<dependencies>
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>3.3.1.GA</version>
</dependency>
</dependencies>
А вот репозиторий JBoss теперь необходимо прописать ручками либо в файле settings.xml, который лежит в корне вашего локального репозитория, либо в самом файле pom.xml, в зависимости от того, нужен ли данный репозиторий во всех проектах, либо в каком-то одном конкретном, соответственно:
<!-- JBoss RichFaces Repository -->
<repositories>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<id>repository.jboss.com</id>
<name>Jboss Repository for Maven</name>
<url>
http://repository.jboss.com/maven2/
</url>
<layout>default</layout>
</repository>
</repositories>
Как правило на сайтах крупных проектов пишут всю информацию, необходимую для встраивания их библиотеки в проект на основе Maven, но бывают случаи, когда артефакт приходится искать очень и очень долго. Здесь нам очень сильно может помочь MVNrepository.com — он вам всегда подскажет где может находиться искомая библиотечка. Но если уж и там не нашлось, то из собственного опыта могу посоветовать гуглить «<название библиотеки> pom.xml». Бывает так, что проекты уже давно закрыты и в репозитории не положены потому что разработчики уже не заботятся об их распространении. Тогда остается один единственный способ – добавить файл в репозиторий вручную командой:
mvn install:install-file
-Dfile=<path-to-file>
-DgroupId=<group-id>
-DartifactId=<artifact-id>
-Dversion=<version>
-Dpackaging=<packaging>
Последний параметр чаще всего имеет значение jar.
Плагины
Так как плагины являются такими же артефактами, как и зависимости, то они описываются практически так же. Вместо раздела dependencies – plugins, dependency – plugin, repositories – pluginRepositories, repository – pluginRepository.
Плагинами Maven делает все, даже непосредственно то, для чего он затевался – сборку проекта, только этот плагин необязательно указывать в свойствах проекта, если вы не хотите добавить какие-то фичи.
Посмотрим как настроить плагин для создания проекта для Eclipse с использованием WTP ver. 2.0. В раздел plugins нашего pom.xml прописываем следующий плагин:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<wtpversion>2.0</wtpversion>
</configuration>
</plugin>
Теперь идем опять таки в командную строку и выполняем команду
mvn eclipse:eclipse
Ждем пока Maven найдет все библиотеки в репозитории или скачает их и вуаля – теперь наш Maven-проект можно открыть как проект eclipse. При этом библиотеки никуда не копируются как при классическом подходе, а остаются в репозитории и Eclipse делает на них ссылку через свои переменные.
Единого списка всех плагинов естественно не существует, на официальном сайте только есть поддерживаемые плагины непосредственно разработчиками Maven. Однако хотелось бы отметить, что названия плагинов довольно прямолинейны и сделав поиск по ключевым словам «maven tomcat plugin» вы скорее всего обнаружите первой ссылкой плагин для деплоймента проекта в Tomcat.
Собственный репозиторий
К сожалению сам не имею большого опыта настройки репозитория, но могу посоветовать как наиболее простой и распространенный Nexus. За дополнительной информацией следует обратиться на сайт данного проекта.
Однако нельзя оставить без внимания и достойных конкурентов в лице Artifactory и Archiva.
Заключение
Очень надеюсь, что цель данной статьи достигнута – минимальных знаний по Maven должно хватить на работу с не очень большими проектами. Для более серьезных целей очень советую детально изучить maven-compiler-plugin и maven-resource-plugin – они напрямую отвечают за конечную компоновку проекта. Я считаю, что самым главным моментом в обучении Maven является понимание идеологии – Maven описывает конечную структуру проекта, а не пути к ее достижению, в отличие от Ant.
Полезные ссылки
Официальная страница Maven
Документация
Центральный репозиторий
Репозиторий iBiblio
Поиск артефактов по названию
Неплохой форум по Maven
Maven: The Definitive Guide — хорошая книга по Maven
#статьи
-
0
Собираем проект на Java быстро, без регистрации и СМС.
Иллюстрация: Lip Kee / Apache Software Foundation / Wikimedia Commons / John Fowler / Maksym Ostrozhynskyy / Brett Wharton / Ben Kolde / Unsplash / Дима Руденок для Skillbox Media
Пишет о сетях, инструментах для разработчиков и языках программирования. Любит готовить, играть в инди‑игры и программировать на Python.
Если спросить у Java-разработчика, кто его лучший друг, то, скорее всего, он расскажет про Apache Maven. Это фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (Project Object Model).
Пока что звучит сложно, но в этой статье мы разберёмся в основах работы со сборщиком проектов и заглянем в его сердце — файл pom.xml.
Что вы узнаете про Maven:
- зачем он нужен и есть ли у него аналоги;
- как его правильно установить на компьютер и можно ли обойтись без этого;
- как его настроить и собрать свой первый проект;
- зачем ему репозитории и какими они бывают.
Maven — это инструмент для автоматической сборки проектов на Java и других языках программирования. Он помогает разработчикам правильно подключить библиотеки и фреймворки, управлять их версиями, выстроить структуру проекта и составить к нему документацию.
Например, чтобы собрать приложение для управления базами данных на Java, нам понадобятся фреймворки Spring и Hibernate, библиотека JUnit для модульного тестирования и сама база данных. Всё это можно собрать в одном проекте вручную, но могут быть трудности из-за большого числа зависимостей. Здесь на помощь разработчикам приходит Maven. Он автоматически добавит эти или другие зависимости в проект и соберёт его в исполняемый файл.
Maven — не единственный сборщик проектов. Некоторые разработчики используют его аналоги — Gradle и Ant. Но именно Maven сегодня — золотой стандарт в индустрии.
Maven можно установить вручную или воспользоваться IDE с предустановленным сборщиком. Второй вариант удобнее и быстрее, но начнём мы с обычной установки в операционную систему.
Важно! Чтобы работать с Java, у вас на компьютере должен быть установлен и настроен JDK. Мы уже писали, как это сделать правильно.
Скачайте архив со сборщиком для своей операционной системы с официального сайта Apache Maven и распакуйте его. Лучше всего создать для этого отдельную папку, так как путь к ней нам понадобится позже.
Если у вас Linux, то установку можно запустить через командную строку:
sudo команда-вашего-пакетного-менеджера maven
Для удобной работы с Maven и его запуска в командной строке или терминале необходимо прописать переменные среды. На разных операционных системах этот процесс различается.
Windows
Процесс установки на Windows 7, 10 и 11 одинаков. Нажмите правой клавишей мыши на Этот компьютер и выберите пункт меню Свойства. Теперь пройдите через несколько окон: Дополнительные параметры системы → Дополнительно → Переменные среды.
В окне Переменные среды найдите переменную Path и нажмите на кнопку Изменить:
Скриншот: Skillbox Media
В открывшемся окне нажмите кнопку Создать и укажите полный адрес до папки bin из распакованного архива Maven:
Проверьте настройку переменных среды. Для этого зайдите в командную строку и введите mvn -v. Если Maven установлен, то появится информация о его версии:
Linux/Mac
Откройте в текстовом редакторе файл ~/.bashrc или ~/.bash_profile в Linux или .zshrc в macOS. Файл находится в домашней директории текущего пользователя. Если файла нет, создайте его и впишите:
export PATH="<path_to_maven>:$PATH"
Вместо path_to_maven указываем путь к файлу ~/.bashrc или ~/.bash_profile в Linux или .zshrc в macOS.
Проверьте настройку переменных среды. Для этого зайдите в терминал и запустите mvn -n. Должно появиться сообщение с версией Maven:
Для Mac в последней строке будет указано family: «mac».
Для работы с Maven мы будем использовать IntelliJ IDEA. Это удобная среда разработки, в которой сборщик проектов установлен из коробки.
Настройки Maven в IDE можно найти в правой части рабочей области после создания проекта на Java:
Начнём работу с создания шаблона проекта. Среда разработки и здесь сэкономит нам время, так как самостоятельно пропишет необходимые параметры.
Создайте новый проект:
Программа предложит выбрать Maven Archetype в качестве шаблона сборки. Кликните на него и в окне преднастроек выберите Archetype quickstart. Нажмите Create:
В окне проекта вы увидите, как Maven зашёл в репозитории и начал что-то скачивать, — это нормально:
Слева на экране показана структура проекта. Нам нужен класс App.java, в котором находится метод main. Чтобы найти его, откройте папку src, затем main и java. Внутри App.java хранится небольшой фрагмент кода:
package org.example; /** * Hello world! * */ public class App { public static void main( String[] args ) { System.out.println( "Hello World!" ); } }
Метод работает просто — он выводит в консоль сообщение Hello World!.
Теперь перейдите к файлу pom.xml. Это основной конфигурационный файл в проекте, который описывает его структуру, зависимости и настройки. Можно сказать, что это главная сила всего Maven.
Если открыть файл, то увидим такой код:
<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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>maven-example</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>maven-example</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
Разберём, что к чему:
project — корневой элемент, содержащий всю информацию о проекте.
xmlns, xmlns:xsi, xsi:schemaLocation — это атрибуты для указания пространства имён и схемы для pom.xml. Проще говоря, здесь указано, что должно содержаться в файле и как это всё должно быть расположено.
modelVersion — версия модели POM, которую данный файл использует. У нас версия 4.0.0.
groupId, artifactId, version — это обязательные элементы для идентификации содержимого проекта.
- groupId — это идентификатор команды. В нашем случае — org.example, как и пакет с классом App. В больших компаниях идентификатор определяет группу или команду разработчиков. Например, представим, как мог бы выглядеть идентификатор компании ACME. Веб-разработчики в ней будут использовать идентификатор группы com.acme.webapps, а мобильные разработчики — com.acme.mobile.
- artifactId — это идентификатор артефакта. Артефактами Maven называет приложения, пакеты и файлы. Как и идентификатор группы, он нужен, чтобы не запутаться в проекте. По умолчанию идентификатор артефакта соответствует имени проекта, которое мы указали при его создании. У нас это maven-example.
- version — версия проекта. Меняется при обновлении проекта.
packaging — тип упаковки проекта. У нас всё упаковывается в JAR-файл.
name — имя проекта.
url — URL-адрес, связанный с проектом.
properties — здесь указываем переменные проекта. В нашем случае мы прописываем только кодировку, задавая её по умолчанию как UTF-8. Точно так же мы можем указать версии зависимостей, конфигурации плагинов, фильтры ресурсов и другие параметры. Полный список настроек доступен в документации Maven.
Работают properties так: прописываете информацию в pom.xml, потом подставляете в нужном вам месте конструкцию с названием созданной вами properties — ${имя_properties}. Это если значение нужно упомянуть в pom.xml. В классах значение properties получаем через геттеры:
String appVersion = System.getProperty("app.version");
dependencies — здесь определяются зависимости проекта — библиотеки, которые будут использоваться. В нашем указана только зависимость от JUnit версии 3.8.1. В dependencies, так же как и для всего проекта, прописываются идентификаторы groupId, artifactId и version. Только здесь они прописаны для каждой библиотеки по отдельности.
scope указывает на то, для чего библиотека используется. Мы прописали область test — JUnit будет доступен только для запуска тестов, но не будет включён в основной код проекта.
Теперь запустим наш проект. Для этого нажмите run в окне App.java:
Всё сработало как надо — появился текст Hello World!:
Поздравляем! Вы собрали первый проект в Maven.
Maven умеет не только выводить что-то в консоль. Его мощь — в библиотеках, которые можно подключить к проекту. Для этого используются репозитории.
Репозитории Maven — это хранилища, где находятся библиотеки. Что-то вроде Google Play или App Store, но для сборщика проектов. Репозитории бывают локальными и удалёнными. Последние делятся на общедоступные и сторонние.
Локальный репозиторий расположен на вашем компьютере. Там Maven хранит библиотеки, которые вы используете в своих проектах.
Когда вы загружаете библиотеку в первый раз, Maven сохраняет её в локальном репозитории. Все последующие проекты используют уже загруженную версию, что позволяет сэкономить время на её скачивании.
Общедоступный, или центральный, репозиторий — это хранилище библиотек, предоставляемых Apache Maven. Именно к нему обращается сборщик по умолчанию.
Сторонние репозитории предоставляют какие-либо организации или сообщества. Чтобы Maven искал библиотеки именно в них, необходимо это настроить.
Библиотеки могут быть в состоянии снапшота (SNAPSHOT) или релиза (release). Снапшоты — это версии библиотек в разработке. Они могут меняться внутри без изменения номера версии. Это может привести к проблемам, так как версия библиотеки остаётся прежней, но её функциональность может измениться. Релизы — стабильные версии библиотек, которые не изменяются, а выпускаются под конкретным номером. Лучше всего использовать именно их.
Настройки работы Maven с репозиториями прописаны в settings.xml. Сам файл находится в папке conf вашей директории с Maven:
Откройте settings.xml в любом текстовом редакторе. Там много кода, но нам нужна секция <mirrors>. По умолчанию она выглядит так:
<mirrors> <!-- mirror | Specifies a repository mirror site to use instead of a given repository. The repository that | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used | for inheritance and direct lookup purposes, and must be unique across the set of mirrors. | <mirror> <id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://my.repository.com/repo/path</url> </mirror> --> <mirror> <id>maven-default-http-blocker</id> <mirrorOf>external:http:*</mirrorOf> <name>Pseudo repository to mirror external repositories initially using HTTP.</name> <url>http://0.0.0.0/</url> <blocked>true</blocked> </mirror> </mirrors>
Что тут есть:
id — уникальный идентификатор для данного зеркала. В этом случае ID установлен как maven-default-http-blocker. Такая конфигурация блокирует внешние репозитории, использующие протокол HTTP. Это полезно, когда мы хотим пользоваться только локальными репозиториями.
mirrorOf — этот элемент указывает, для каких репозиториев будет применяться зеркало. У нас прописан шаблон external:http:*, который означает, что сборщик будет блокировать все внешние репозитории, использующие протокол HTTP, без каких-либо ограничений.
name — имя и описание для зеркала.
url — URL зеркала. Здесь указан фиктивный URL http://0.0.0.0/ в качестве заглушки.
blocked — определяет, блокируется указанное зеркало или нет. У нас установлено значение true, то есть доступ к внешним репозиториям заблокирован.
Если мы хотим, чтобы Maven искал библиотеки в других репозиториях, то должны добавить в <mirrors> блок по шаблону:
<mirror> <id>external-repos</id> <url>https://repo.example.com/maven2</url> <mirrorOf>external:*</mirrorOf> </mirror>
В url впишите адрес желаемого репозитория. Теперь Maven сможет его найти.
Резюмируем всё, что мы узнали про сборщик проектов:
- Maven облегчает рутинные задачи по сборке проектов на Java и некоторых других языках программирования.
- Главная сила Maven — это pom-файлы, позволяющие точно настроить сборку проекта с учётом всех используемых библиотек и фреймворков.
- Для хранения библиотек используются репозитории. Они могут быть локальными, то есть располагаться на вашем компьютере, и удалёнными. Это позволяет гибко настроить доступ к библиотекам и использовать нужные нам версии.
Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше
- →
Apache Maven (обычно называют просто Maven) — это фреймворк по автоматизации и управлению сборкой Java-приложений. Слово Maven взято из языка идиш, примерный перевод которого можно выразить как «собиратель знания» (accumulator of knowledge), «эксперт».
Apache Maven, по большей части, написан на Java. Это проект с открытым исходным кодом, который следует философии «Соглашение важнее конфигурации» (convention over configuration).
1. Основные возможности Maven
Наиболее важные возможности Maven:
- Простая настройка проекта в соответствии с лучшими практиками
- Управление зависимостями, включая автоматическое обновление
- Возможность работать с несколькими проектами одновременно
- Большое хранилище библиотек и метаданных для использования «из коробки»
- Расширяемость с возможностью написания своих плагинов
- Создание сайта и PDF с документацией
- Проверка корректности структуры проекта
- Компиляция исходного кода, отображение ошибок/предупреждений
- Тестирование проекта на основе уже написанных тестов
- Упаковка скомпилированного кода в артефакты (например, .jar, .war, .ear, .zip-архивы и многое другое)
- Упаковка исходного кода в загружаемые архивы/артефакты
- Установка упакованных артефактов на сервер для последующего развертывания (деплоя) или в репозиторий для распространения
- Создание отчетов по тестированию
- Сообщение об удачной/неудачной сборке проекта
2. Принцип «Соглашение важнее конфигурации»
Соглашение важнее конфигурации — это принцип проектирования программного обеспечения, целью которого является уменьшение количества лишних действий, необходимых разработчику при создании своего проекта.
В Apache Maven данный принцип проявляется в том, что Maven предоставляет разумные настройки (готовые шаблоны) по умолчанию для управления сборкой проекта. Если они не подходят, то разработчик может переопределить их на свои.
Одной из таких настроек по умолчанию, например, является структура каталогов в Maven-проекте (подробнее о стандартных каталогах):
В этой структуре исходный код, в соответствии с соглашением, располагается в подкаталоге src/main/java. В каталоге test находится код тестов.
Аналогичным образом ресурсы, необходимые для приложения или его тестирования, находятся в каталоге resources.
Это всего лишь один из множества примеров стандартизации в соответствии с философией «Соглашение важнее конфигурации».
Maven использует объектную модель проекта (Project Object Model, POM) для управления проектом. Для описания модели обычно используется XML-документ, но возможны и другие форматы.
Рисунок, иллюстрирующий типичную работу Maven
4. Что такое Объектная модель проекта (POM)?
POM — это очень полезная и удобная вещь, которая описывает то, как будет собираться проект. Этот файл (обычно pom.xml) состоит из следующих частей:
- Project coordinates (координаты проекта) — однозначно идентифицируемый набор свойств, с помощью которых артефакты проекта могут быть использованы в другом месте
- Dependencies (зависимости) — библиотеки и код, необходимые для сборки проекта
- Plugins (плагины) — вспомогательные инструменты при сборке проекта
- Properties (свойства) — общие значения, необходимые проекту
- Inheritance details (детали наследования) — возможность создания иерархии для повторно используемых компонентов POM
- Profiles (профили) — альтернативные пути сборки проекта, разбитые по профилям
4.1. Как Maven взаимодействует с POM?
Maven использует содержимое в POM для управления сборкой. Однако он также имеет стандартные значения по умолчанию. Таким образом, Maven несет ответственность за объединение значений по умолчанию и применение переопределений и дополнений, обнаруженных в pom-файле проекта.
Благодаря этому мы получаем:
- совокупность шагов выполнения, свойств и профилей
- контент, который Maven может выполнить для проекта
- исчерпывающий набор зависимостей и плагинов, необходимых для такого выполнения
- определение любых переходных зависимостей (например, зависимости зависимостей)
- разрешение конфликтов с точки зрения версий зависимостей
4.2. Как Maven собирает POM?
Maven собирает свой POM, проходя слои, которые действуют как строительные блоки. Каждый используемый слой имеет возможность переопределять или дополнять содержимое того, что станет POM. Родительские файлы, спецификации и файлы POM-проекта — это то, где можно переопределить настройки Maven по умолчанию.
Теперь пройдемся по существующим слоям:
Внутренние настройки Maven
Этот слой находится в коде Maven. Если не предполагается править его исходник, то эти значения по умолчанию можно считать неизменяемыми.
Этот супер-POM также является частью кода Maven. Опять же, если цель не состоит в том, чтобы изменить исходник, то также можно считать, что Super POM является неизменяемым.
Глобальные настройки Maven
После установки Maven создает структуру каталогов. Одним из базовых каталогов является conf, содержащий файл глобальных настроек settings.xml. Поскольку этот файл существует на локальном компьютере, он доступен для редактирования. Как правило, любые параметры, которые применяются ко всем проектам, управляемым на конкретном компьютере, прописываются в этом глобальном settings.xml. Например, в этот файл входят такие параметры, как настройки прокси-сервера, URL-адреса корпоративных серверов, зеркала и т. д. В любом случае его не следует часто изменять.
Расположение:
Unix/MacOS: <maven installation>/conf/settings.xml
Windows: <maven installation\conf\settings.xml
Пользовательские настройки Maven
Аналогично глобальным настройкам, но в другом месте, можно создать файл пользовательских настроек. Этот файл также называется settings.xml, но его местоположение находится в папке пользователя (user home) в каталоге .m2 (скрытая папка). Данный файл предназначен для настройки любых параметров, применимых к проектам. Управляется конкретным пользователем (на данном компьютере может быть несколько пользователей). Это могут быть имена пользователей и пароли для подключения к сети, параметры репозитория и т. д.
Расположение:
Unix/MacOS: <user.home>/.m2/settings.xml
Windows: <user.home>\.m2\settings.xml
Родительские POM’ы / спецификации
Maven позволяет наследовать содержимое от родительского POM и характеристики версий из pom-спецификации. Обычно родительские POM содержат повторно используемые зависимости, плагины и свойства, используемые POM проекта. POM-спецификации (Bill-of-Material — BOM) — это специализированный POM, который позволяет группировать версии зависимостей. Использование POM-спецификации избавляет разработчика от необходимости проверять совместимость различных зависимостей. Изменение любого из них возможно, если есть необходимость и право на изменение. Поскольку изменения в любом из них могут повлиять на несколько других проектов, для изменений рекомендуется соответствующее увеличение версий и их пересмотр.
Расположение:
Различные места на компьютере или в каком-либо репозитории.
Это Project Object Model для проекта. В этом месте подробно описаны инструкции Maven для конкретного проекта. Типичное содержимое включает в себя: уникальный набор координат, используемых для идентификации проекта; название и описание проекта; набор разработчиков, связанных с проектом; любые сведения об управлении системой контроля версиями; все зависимости и плагины для конкретного проекта; любые профили, которые позволяют поочередно выполнять Maven в этом проекте и так далее. Все это будет описано в последующих статьях. Файл, содержащий этот POM, называется pom.xml, но можно использовать и другие имена. Если используется альтернативное имя, то исполняемому файлу Maven необходимо будет указать имя файла для выполнения.
Расположение:
Unix/MacOS: $PROJECT/pom.xml
Windows: $PROJECT\pom.xml
6. Координаты зависимостей
Существуют сотни или тысячи проектов, которые собраны в артефакты. Некоторые из этих артефактов потенциально могут быть использованы в текущем проекте в качестве библиотек. Например, проект может зависеть от логирования или библиотеки JSON. В центральном репозитории можно разместить множество артефактов зависимостей. Основное такое хранилище Maven называется Maven Central. Существует также множество других подобных хранилищ.
Следующий вопрос заключается в том, как определить и загрузить точные артефакты, необходимые для проекта? Правильный способ идентифицировать артефакт — это использовать его координаты Maven.
Что такое координаты Maven?
Это способ уникальной идентификации артефакта. Существуют три основные координаты, которые используются для идентификации артефакта.
Классификация по группе, обычно относящаяся к организации или компании и может иметь общее название для одного или нескольких проектов. groupId обычно описан через точку (аналогично имени пакета Java). Каждый элемент в этой точечной нотации соответствует каталогу в древовидной структуре хранилища. Например, groupId в org.apache.commons соответствует $REPO/org/apache/commons.
Наличие точечной нотации не является обязательным требованием (хотя очень рекомендуется).
Это точное название проекта. Среди множества проектов, существующих в группе, artifactId может однозначно идентифицировать артефакт. Если название состоит из нескольких слов, то в описании artifactId оно разделяется дефисами. В идеале, имена должны быть небольшой длины.
Артефакт проявляется в виде подкаталога в дереве каталогов, представленного groupId. Например, artifactId commons-lang3 в groupId org.apache.commons сообщает, что артефакт можно найти в разделе: $REPO/org/apache/commons/commons-lang3/.
Это идентификатор, который отслеживает уникальные сборки артефакта. Версия — это строка, созданная разработчиками проекта для определения набора изменений, внесенных в предыдущее создание артефакта того же проекта. Настоятельно рекомендуется следовать схемам семантического управления версиями, хотя это не обязательно.
Версия проявляется в виде подкаталога в дереве каталогов, который состоит из groupId и artifactId. Например, version 3.1.0 для artifactId commons-lang3 в groupId org.apache.commons обозначает, что артефакт находится в $REPO/org/apache/commons/commons-lang3/3.1.0/.
Теперь немного подробнее про версии.
Следуя стандартным жизненным циклам разработки программного обеспечения (ПО), проект может проходить этапы разработки, каждый из которых состоит из нескольких попыток создания ПО: тестирование, исправление ошибок, внесение дальнейших необходимых изменений и т. д. Как только цикл завершается, продукт помечается для релиза (выпуска). Эти жизненные циклы и фазы не имеют ничего общего с Maven.
Во время разработки продукта может быть создано несколько артефактов, которые можно протестировать, проверить и т. д. Этот цикл разработки обычно создает артефакты с той же версией, что и предыдущие сборки на том же этапе. Основанием для этого утверждения является то, что релиз все еще находится в экспериментальном, бета- или альфа-состоянии, но может претерпеть дополнительные изменения. Однако трудно заставить все проекты постоянно обновлять свои собственные POM для каждой такой сборки. В этой проблеме помогает создание SNAPSHOT’ов (снимков).
Например, для проекта A версии 1.0.0 команда разработчиков может создать несколько версий SNAPSHOT’ов с версией 1.0.0-SNAPSHOT в течение определенного периода времени. Этот суффикс подразумевает, что номер версии в конце должен быть 1.0.0, однако при каждой сборке будут создаваться новые артефакты, которые заменят предыдущий SNAPSHOT. Более новый SNAPSHOT может заменить существующий SNAPSHOT артефакта в репозитории Maven, поэтому пользовательские проекты могут безопасно получить последнюю версию SNAPSHOT’а. SNAPSHOT — это изменяемая версия проекта, которая может быть объявлена как зависимость в пользовательских проектах.
Готово для выпуска в продакшн (Production-Ready)
После завершения всего тестирования POM больше не нуждается в суффиксе SNAPSHOT и может создать готовую к продакшену неизменяемую версию проекта. Как только она будет помещена в репозиторий, в нее нельзя вносить никаких дальнейших изменений (Maven не позволяет это делать по своим внутренним правилам). Обычно можно найти другие готовые к производству суффиксы: 1.0.0-GA (общая доступность) или 1.0.0-RELEASE (выпущенный артефакт) или 1.0.0-FINAL и т. д. Опять же, строки версий вообще не имеют значения для Maven.
Распространенный способ передачи координат артефактов — это разделение двоеточием. Вместе координаты называются Group-Artifact-Version или координатами GAV. Координаты GAV для commons-lang3 версии 3.1.0 будут следующими: org.apache.commons:commons-lang3:3.1.0.
Дополнительные различители
Часто сборка проекта может включать более одного формата артефактов. Выполнение Maven в проекте может привести к созданию jar, zip, архива и многих других артефактов. Выполнение также может выдавать различные выходные данные, такие как двоичный код, zip-файл исходных текстов, zip файлов javadoc и т. д.
Таким образом, помимо вышеупомянутых координат GAV, для идентификации таких разнообразных результатов необходимы различители.
classifier используется для разграничивания альтернативного вывода, получаемого при выполнении Maven в POM проекта. Распространенные примеры включают источники в виде файла jar/zip и javadoc в виде файла jar/zip. classifier задается как часть имени артефакта. Для нашего приведенного выше примера commons-lang3 артефакт, который нужно искать, таков: commons-lang3−3.10-javadoc.jar или commons-lang3−3.10-sources.jar в $REPO/org/apache/commons/commons-lang3/3.1.0/.
type используется для разграничивания формата артефакта. Артефакты, создаваемые в результате выполнения Maven, могут быть различных типов, как уже обсуждалось: .jar, .war, .zip и т. д. Иногда для проекта может быть полезно создавать артефакты в разных форматах. Эти форматы указаны в type.
Комбинация GAV-координат и различителей может использоваться для определения точного артефакта, необходимого для проекта.
Этот раздел описывает иерархию в POM’ах в Maven.
Родительский POM — это POM, от которого текущий POM проекта может наследовать содержимое. POM проекта может зависеть только от одного родительского POM. Это наследование от одного родителя является односторонним. Родительский POM не знает о POM, который наследуется от него. Дочерний POM заявляет о своем происхождении по своему pom.xml.
Любое количество POM может объявить другой POM своим родителем.
Примечание: родительский POM можно использовать для объявления повторно используемых частей POM, которые затем могут унаследовать отдельные дочерние POM. Это помогает как в обслуживании, так и в уменьшении беспорядка.
POM-агрегатор (также известный как POM-реактор) — это POM, который может упорядочивать сборки многих проектов. POM-агрегатор определяет все проекты, которыми можно управлять при сборке вместе. Дочерние POM’ы остаются в неведении о POM-агрегаторе, который его вызывает. Дочерний POM может быть указан в нескольких POM-агрегаторах. POM-агрегатор перечисляет дочерние POM’ы по name (имени) в своем собственном pom.xml в качестве module (модуля).
Как следует из объявленного модуля, этот шаблон предназначен для модульных сборок проектов. Нет наследования какого-либо содержимого от POM-агрегатора.
Примечание: POM-агрегатор можно использовать для обеспечения последовательности сборок и ведения списка проектов, которыми следует управлять совместно.
Спецификация POM (Bill-Of-Materials)
POM-спецификация — это POM, который может объявлять наборы зависимостей, которые были протестированы для их совместной работы. Обилие артефактов и версий каждого из них иногда может привести к путанице и потребности в механизмах проб и ошибок для определения совместимости и/или правильной функциональности.
POM-спецификация уменьшает эти хлопоты. POM-спецификация также является средством множественного наследования, поскольку POM проекта может импортировать несколько POM-спецификаций. POM-спецификация не знает о дочерних POM’ах, которые его импортируют. Дочерние POM’ы объявляют спецификацию POM’е проекта.
Примечание: POM-спецификацию можно использовать для объединения хорошо работающих зависимостей (с правильными версиями) вместе, чтобы избежать повторения для каждого проекта.
POM может быть как родителем (parent), так и агрегатором (aggregator). Это обеспечивает двустороннюю связь в тесно связанном наборе модулей, которые зависят от общего набора унаследованного содержания.
Оцените статью, если она вам понравилась!
Maven – основные понятия
Maven – это средство для управления и сборки проектов. Он позволяет разработчикам полностью управлять жизненным циклом проекта. Благодаря этому, команда может автоматизировать процессы, связанные со сборкой, тестирование, упаковкой проекта и т.д.
В случае, когда над проектом работает несколько команд разработчиков, Maven позволяет работать в соответствии с определенными стандартами.
Вот основные аспекты, которыми позволяет управлять Maven:
- Создание
- Документирование
- Отчёты
- Зависимости
- Релизы
- SCM
- Список рассылки
- Дистрибьюция
Для чего Maven создан?
Основной целью Maven является предоставление разработчику:
- Понятной модели для проектов, которая может быть использована повторно и была бы проста в поддержании.
- Плагины, которые могут взаимодействовать с этой моделью.
Структура и содержание проекта Maven указывается в специальном xml-файле, который называется Project Object Model (POM), который является базовым модулем всей системы.
Соглашение по конфигурации
В Maven используется Соглашение по конфигурации.
Разработчики не обязаны указывать каждую деталь. Maven обеспечивает поведение проекта по умолчанию. Когда мы создаём проект с использованием этой технологии, то Maven создаёт базовую структуру проекта. Разработчики несут ответственность только за соответственное размещение файлов.
Ниже указаны значения по умолчанию для исходного кода проекта и других модулей.
| исходный код | /src/main/java |
| Ресурсы | /src/main/resources |
| Тесты | /src/test |
| Дистрибутив JAR | /target |
| Скомпилированный байт-код | /target/classes |
Для того, чтобы построить проект, Maven предоставляет нам настройки для управления жизненным циклом проекта и его зависимостями. Большая часть его задач поддерживается плагинами Maven.
Мы даже можем создавать проекты с использованием Maven без понимания того, как работают эти отдельные плагины.
В этом уроке мы изучили базовые понятия фреймворка Maven.
В следующем уроке мы изучим файл POM.xml
Мавен – это фреймворк автоматической сборки проектов с широким функционалом – достаточно широким, чтобы неподготовленный разработчик, зашедший в эти дебри, заработал головную боль, сломал себе проект и ногу, а то и обе. Сегодня мы попробуем буквально за 10 минут освоить главные фишки мавен : управление зависимостями, в том числе транзитивными, и автоматическую сборку. Если вдруг вы не знакомы с понятием транзитивных зависимостей, это цепочка A ← B ← C, где A зависит от В, а В от С. Maven позволяет не запариваться по этому поводу, и если вам нужен именно А, указывать только его, об остальном позаботится за вас.
Я предполагаю, что у вас уже установлена java, если нет, то срочно это исправьте. Maven использует декларативный подход, где все инструкции записываются на языке разметки POM – обычном XML с рядом предопределенных сущностей. В данной статье примеры будут достаточно просты, так что курсы XML пока можно отложить.
Установка Maven.
Задача проста.
- Идем на главный сайт проекта, скачиваем подходящий для вашей системы архив и распаковываем в удобную директорию, желательно без кириллицы в названии.
- Прописываем директорию в переменные окружения PATH.
- Рекомендую проверить наличие в PATH JAVA_HOME.
Первый проект Maven
Все современные IDE позволяют создать проект maven буквально двумя кликами, но мы не станем срезать путь. Для создания простейшей директории запустите в консоли команду:
mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app -DartifactId=test-app
Мы создали классический «Hello, world», разберём его в деталях. Первое, во что мы упираемся, – это archetype, так в Maven называются шаблоны. Команда archetype:generate создает проект по архетипу. В нашем случае id по умолчанию приравнивается к 15 или maven-archetype-quickstart.
Чтобы задать шаблон, просто добавьте в команду
-DarchetypeArtifactId=maven-archetype-quickstart
Полный список доступных шаблонов можно посмотреть на сайте или отдельно в консоли вбить mvn archetype:generate. Следом идет archetypeGroupId – что-то вроде пространства имён шаблонов. GroupId – обычно используется для указания производителя. Artifact – это название нашего проекта. Собственно, артефакты – это главная сущность в Maven, из них состоит всё.
На выходе получаем такую структуру:
test-app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- com
| `-- mycompany
| `-- app
| `-- App.java
`-- test
`-- java
`-- com
`-- mycompany
`-- app
`-- AppTest.java
В корне видим сгенерированный файл 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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>test-app</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Большая часть этого файла сгенерирована и не нуждается в корректировке на стартовом этапе, кроме тега dependencies, именно здесь нужно будет объявлять зависимоcти, каждую в отдельном теге dependency. Сейчас там указана только библиотека для тестирования junit.
Важные тонкости
Напоследок хочу обратить внимание на несколько пунктов. По умолчанию Maven работает с java 1.6, чтобы это поправить, нужно внутри тега project добавить следующий код, заменив {Ваша версия java} на соответствующий номер.
<properties>
<maven.compiler.release>{Ваша версия java}</maven.compiler.release>
</properties>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
</plugin>
</plugins>
</pluginManagement>
</build>
Поздравляю, проделанной работы достаточно, чтобы прописать команду сборки:
mvn package
Фреймврок автоматически пройдет цепочку из 6 этапов, и теперь остается только запустить:
java -cp target/test-app-1.0-SNAPSHOT.jar com.mycompany.app.App
Наслаждаемся результатом трудов! =)
Этого должно быть достаточно для базового понимания Maven. Если вы загорелись идеей освоить этот инструмент и использовать весь его функционал, стоит начать с детального изучения super POM, шаблонов и плагинов. Удачи вам в освоении новых рубежей 
