Руководство по maven что такое maven

Время на прочтение
6 мин

Количество просмотров 515K

После публикации топика о 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 FilesJavajdk1.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 Settingsusername.m2repository

Все, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

export PATH=/opt/apache-maven-3.6.0/bin:$PATH

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

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T21:41:47+03:00)
Maven home: C:apache-maven-3.6.0bin..
Java version: 10.0.1, vendor: Oracle Corporation, runtime: C:Program FilesJavajdk-10.0.1
Default locale: ru_RU, platform encoding: Cp1251
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

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

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

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

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.

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

my-app

|-- pom.xml

`-- src

    |-- main

    |     `-- java

    |         `-- com

    |             `-- mycompany

    |                 `-- app

    |                     `-- App.java

    `-- test

        `-- java

            `-- com

                `-- mycompany

                    `-- app

                        `-- AppTest.java

Исходники нашего проекта будут лежать в папке src/main/java (и сейчас там уже есть автоматически сгенерированный файл), но нам сейчас интереснее файл pom.xml в корневом каталоге. Это и есть тот самый файл описания проекта, на основе которого осуществляются все операции Maven. Он написан на языке 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>my-app</artifactId>
   <version>1.0-SNAPSHOT</version>
   <name>my-app</name>

   <!-- FIXME change it to the project's website -->
   <url>http://www.example.com</url>

   <properties>
      <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
      <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.11</version>
         <scope>test</scope>
      </dependency>
   </dependencies>

   <build>
      <pluginManagement>
         <plugins><...></plugins>
      </pluginManagement>
   </build>
</project>

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

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

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

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

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

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

Следом идёт очень важный блок dependencies. В нём описываются все используемые в проекте зависимости. Каждую необходимо выделить тегом dependency и указать уникальные идентификационные данные: groupIdartifactId и 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:

<build>
    <resources>
        <resource>
            <directory>src/main/another_resources_directory</directory>
        </resource>
    </resources>
</build>

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

[INFO] ----------------------< com.mycompany.app:my-app >----------------------
[INFO] Building my-app 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ my-app ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:javaProjectsnew_projectmy-appsrcmainresources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:javaProjectsnew_projectmy-apptargetclasses
[INFO]
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ my-app ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:javaProjectsnew_projectmy-appsrctestresources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ my-app ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:javaProjectsnew_projectmy-apptargettest-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ my-app ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.mycompany.app.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.217 s - in com.mycompany.app.AppTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ my-app ---
[INFO] Building jar: C:javaProjectsnew_projectmy-apptargetmy-app-1.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  20.670 s
[INFO] Finished at: 2019-02-17T02:25:07+03:00
[INFO] ------------------------------------------------------------------------

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

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

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

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 installationconfsettings.xml

Пользовательские настройки Maven

Аналогично глобальным настройкам, но в другом месте, можно создать файл пользовательских настроек. Этот файл также называется settings.xml, но его местоположение находится в папке пользователя (user home) в каталоге .m2 (скрытая папка). Данный файл предназначен для настройки любых параметров, применимых к проектам. Управляется конкретным пользователем (на данном компьютере может быть несколько пользователей). Это могут быть имена пользователей и пароли для подключения к сети, параметры репозитория и т. д.

Расположение:
Unix/MacOS: <user.home>/.m2/settings.xml
Windows: <user.home>.m2settings.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: $PROJECTpom.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). Это обеспечивает двустороннюю связь в тесно связанном наборе модулей, которые зависят от общего набора унаследованного содержания.

Оцените статью, если она вам понравилась!


1. Вступление

Создание программного проекта обычно состоит из таких задач, как загрузка зависимостей, размещение дополнительных jar-файлов в пути к классам, компиляция исходного кода в двоичный код, выполнение тестов, упаковка скомпилированного кода в развертываемые артефакты, такие как файлы JAR, WAR и ZIP, и развертывание этих артефактов. на сервер приложений или в хранилище.

Apache Maven

автоматизирует эти задачи, сводя к минимуму риск того, что люди совершат ошибки при сборке программного обеспечения вручную и отделит работу по компиляции и упаковке нашего кода от процесса конструирования кода.

В этом руководстве мы собираемся исследовать этот мощный инструмент для описания, создания и управления проектами программного обеспечения Java с использованием центральной части информации —

Project Object Model

(POM) — которая написана на XML.


2. Зачем использовать Maven?

Ключевые особенности Maven:


  • простая настройка проекта в соответствии с лучшими практиками:

    Maven пытается

избегайте как можно большей конфигурации, предоставляя шаблоны проектов
(названный

archetypes

)


управление зависимостями: ** включает автоматическое обновление, загрузку

и проверка совместимости, а также сообщение о зависимости
замыкания (известные также как транзитивные зависимости)


изоляция между зависимостями проекта и плагинами: ** с Maven,

зависимости проекта извлекаются из репозиториев

dependency

в то время как зависимости любого плагина извлекаются из

plugin
репозитории,

приводящие к уменьшению конфликтов, когда плагины начинают
скачать дополнительные зависимости


центральная система репозитория: ** зависимости проекта могут быть загружены из

локальная файловая система или общедоступные репозитории, такие как

Maven Central

  • Чтобы узнать, как установить Maven в вашей системе, проверьте ссылку:/install-maven-on-windows-linux-mac[это руководство по Baeldung]. **


3. Объектная модель проекта

Конфигурирование проекта Maven выполняется через

Project Object Model (POM)

, представленную файлом

pom.xml

.

POM

описывает проект, управляет зависимостями и настраивает плагины для сборки программного обеспечения.


POM

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

POM

:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
           //...
            </plugin>
        </plugins>
    </build>
</project>

Давайте внимательнее посмотрим на эти конструкции.


3.1. Идентификаторы проекта

Maven использует набор идентификаторов, также называемых координатами, чтобы однозначно идентифицировать проект и указать, как должен быть упакован артефакт проекта:


  • groupId

    — уникальное базовое имя компании или группы, которая создала

проект
**

artifactId

— уникальное имя проекта


  • version

    — версия проекта


  • packaging

    — способ упаковки (например,

    WAR

    /

    JAR

    /

    ZIP

    )

Первые три из них (

groupId: artifactId: version

) объединяются, чтобы сформировать уникальный идентификатор, и представляют собой механизм, с помощью которого вы указываете, какие версии внешних библиотек (например, JAR) будут использовать ваш проект.


3.2. зависимости

Эти внешние библиотеки, которые использует проект, называются зависимостями.

Функция управления зависимостями в Maven обеспечивает автоматическую загрузку этих библиотек из центрального хранилища, поэтому вам не нужно хранить их локально.

Это ключевая особенность Maven и обеспечивает следующие преимущества:

  • ** использует меньше памяти за счет значительного сокращения количества скачиваний

отключить удаленные репозитории



делает проверку проекта быстрее

  • ** обеспечивает эффективную платформу для обмена двоичными артефактами внутри

вашей организации и за ее пределами без необходимости каждый раз создавать артефакт из источника **

Чтобы объявить зависимость от внешней библиотеки, вам нужно предоставить

groupId, artifactId

и

version

библиотеки.

Давайте посмотрим на пример:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.3.5.RELEASE</version>
</dependency>

Когда Maven обрабатывает зависимости, он загружает библиотеку Spring Core в ваш локальный репозиторий Maven.


3.3. Хранилища

Репозиторий в Maven используется для хранения артефактов сборки и зависимостей различных типов. Локальный репозиторий по умолчанию находится в папке

.m2/repository

в домашнем каталоге пользователя.

Если в локальном репозитории имеется артефакт или плагин, Maven использует его. В противном случае он загружается из центрального хранилища и сохраняется в локальном хранилище. Центральный репозиторий по умолчанию —

Maven Central

.

Некоторые библиотеки, такие как сервер JBoss, недоступны в центральном хранилище, но доступны в альтернативном хранилище. Для этих библиотек необходимо указать URL-адрес альтернативного хранилища в файле

pom.xml

:

<repositories>
    <repository>
        <id>JBoss repository</id>
        <url>http://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>
  • Обратите внимание, что вы можете использовать несколько репозиториев в своих проектах. **


3.4. Свойства

Пользовательские свойства могут помочь сделать ваш файл

pom.xml

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

  • Свойства Maven являются заполнителями значений и доступны в любом месте

    pom.xml

    с помощью нотации

    $ {name}

    ** , где

    name

    — это свойство.

Давайте посмотрим на пример:

<properties>
    <spring.version>4.3.5.RELEASE</spring.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>
</dependencies>

Теперь, если вы хотите обновить Spring до более новой версии, вам нужно всего лишь изменить значение внутри тега свойства


_ <spring.version>


, и все зависимости, использующие это свойство в своих тегах

<version> _

, будут обновлены.

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

<properties>
    <project.build.folder>${project.build.directory}/tmp/</project.build.folder>
</properties>

<plugin>
   //...
    <outputDirectory>${project.resources.build.folder}</outputDirectory>
   //...
</plugin>


3.5. построить

Раздел

build

также является очень важным разделом Maven

POM. Он предоставляет информацию о Maven

goal

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

build__ по умолчанию выглядит следующим образом:

<build>
    <defaultGoal>install</defaultGoal>
    <directory>${basedir}/target</directory>
    <finalName>${artifactId}-${version}</finalName>
    <filters>
      <filter>filters/filter1.properties</filter>
    </filters>
   //...
</build>
  • Папка вывода по умолчанию для скомпилированных артефактов называется

    target

    , а окончательное имя упакованного артефакта состоит из

    artifactId

    и

    version

    , но вы можете изменить его в любое время.


3.6. Использование

Profiles


Еще одна важная особенность Maven — поддержка

profiles.


profile

— это, по сути, набор значений конфигурации. Используя

profiles

, вы можете настроить сборку для различных сред, таких как Производство/Тестирование/Разработка:

<profiles>
    <profile>
        <id>production</id>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
    </profile>
    <profile>
        <id>development</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
     </profile>
 </profiles>

Как видно из приведенного выше примера, для профиля по умолчанию установлено значение

development

. Если вы хотите запустить

production


profile

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

mvn clean install -Pproduction


4. Жизненные циклы Maven Build

Каждая сборка Maven следует указанному

lifecycle

. Вы можете выполнить несколько сборок

lifecycle


goals

, в том числе для компиляции кода проекта, создания

package,

и

install

файла архива в локальном репозитории зависимостей Maven.


4.1.

Lifecycle Phases


В следующем списке показаны наиболее важные фазы Maven

lifecycle

:


  • validate

    — проверяет правильность проекта


  • compile

    — компилирует предоставленный исходный код в двоичные артефакты


  • test

    — выполняет модульные тесты


  • package

    — упаковывает скомпилированный код в файл архива


  • integration-test

    — выполняет дополнительные тесты, которые требуют

упаковка
**

verify

— проверяет, является ли пакет действительным


  • install

    — устанавливает файл пакета в локальный репозиторий Maven


  • deploy

    — развертывает файл пакета на удаленном сервере или в хранилище


4.2.

Plugins

и

Goals


Maven

plugin

представляет собой набор из одного или нескольких

goals

. Цели выполняются поэтапно, что помогает определить порядок выполнения

goals

.

Богатый список плагинов, которые официально поддерживаются Maven, доступен по адресу

here

. ** Есть также интересная статья о том, как связать:/executetable-jar-with-maven[создать исполняемый файл

JAR

на Baeldung]с использованием различных плагинов.

Чтобы пройти любой из вышеперечисленных этапов, нам просто нужно вызвать одну команду:

Например,

mvn clean install

удалит ранее созданные файлы jar/war/zip и скомпилированные классы (

clean)

и выполнит все фазы, необходимые для установки нового архива (

install)

  • Обратите внимание, что

    goals

    , предоставляемые

    plugins

    , могут быть связаны с различными фазами

    lifecycle

    . **


5. Ваш первый проект Maven

В этом разделе мы будем использовать функциональность командной строки Maven для создания проекта Java.


5.1. Генерация простого Java-проекта

Чтобы построить простой Java-проект, давайте запустим следующую команду:

mvn archetype:generate
  -DgroupId=org.baeldung
  -DartifactId=org.baeldung.java
  -DarchetypeArtifactId=maven-archetype-quickstart
  -DinteractiveMode=false


GroupId

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

ArtifactId

— это имя базового пакета, используемое в проекте, и мы используем стандартный

archetype

.

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

1.0-SNAPSHOT,

и для упаковки будет задано

jar

.

  • Если вы не знаете, какие параметры предоставить, вы всегда можете указать


    _interactiveMode


    =

    true_

    , чтобы Maven запрашивал все необходимые параметры. **

После завершения команды у нас есть проект Java, содержащий класс

App.java

, который является простой программой «Hello World», в папке

src/main/java

.

У нас также есть пример тестового класса в src/test/java. Pom.xml этого проекта будет выглядеть примерно так:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung.java</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung.java</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.1.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Как видите, зависимость

junit

предоставляется по умолчанию.


5.2. Компиляция и упаковка проекта

Следующим шагом является компиляция проекта:

Maven будет проходить все этапы

lifecycle

, необходимые на этапе

compile

для создания исходных текстов проекта. Если вы хотите запустить только фазу

test

, вы можете использовать:

Теперь давайте вызовем фазу

package



_,


, которая создаст файл

jar_

скомпилированного архива:


5.3. Выполнение заявки

Наконец, мы собираемся выполнить наш Java-проект с помощью

exec-maven-plugin

. Давайте настроим необходимые плагины в

pom.xml

:

<build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.6.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.5.0</version>
            <configuration>
                <mainClass>org.baeldung.java.App</mainClass>
            </configuration>
        </plugin>
    </plugins>
</build>

Первый плагин


maven-compiler-plugin

отвечает за компиляцию исходного кода с использованием Java версия 1.8. Https://search.maven.org/classic/#search%7Cga%7C1%7Ca%3A%22exec-maven-plugin%22[

exec-maven-plugin

]ищет

mainClass

в нашем проекте.

Чтобы выполнить приложение, мы запускаем следующую команду:


6. Мультимодульные проекты

Механизм в Maven, который обрабатывает многомодульные проекты (также называемые

aggregator

projects), называется

Reactor

.


Reactor

собирает все доступные модули для сборки, затем сортирует проекты в правильном порядке сборки и, наконец, строит их один за другим.

Давайте посмотрим, как создать многомодульный родительский проект.


6.1. Создать родительский проект

Прежде всего, нам нужно создать родительский проект. Чтобы создать новый проект с именем

parent-project,

мы используем следующую команду:

mvn archetype:generate -DgroupId=org.baeldung -DartifactId=parent-project

Затем мы обновляем тип упаковки внутри файла

pom.xml

, чтобы указать, что это модуль

parent

:

<packaging>pom</packaging>


6.2. Создать проекты субмодулей

На следующем шаге мы создаем проекты субмодулей из каталога

parent-project

:

cd parent-project
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=core
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=service
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=webapp

Чтобы проверить, правильно ли мы создали подмодули, мы смотрим в файле

parent-project pom.xml

, где мы должны увидеть три модуля:

<modules>
    <module>core</module>
    <module>service</module>
    <module>webapp</module>
</modules>

Более того, родительский раздел будет добавлен в

pom.xml

каждого подмодуля:

<parent>
    <groupId>org.baeldung</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>


6.3. Включить управление зависимостями в родительском проекте

Управление зависимостями — это механизм для централизации информации о зависимостях для родительского проекта muti-module и его дочерних элементов.

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

pom.xml

. Это упростит ссылки на артефакты в дочернем

__POM

__s.

Давайте посмотрим на пример родительского

pom.xml

:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>4.3.5.RELEASE</version>
        </dependency>
       //...
    </dependencies>
</dependencyManagement>

Объявляя версию

spring-core

в родительском объекте, все подмодули, зависящие от

spring-core

, могут объявить зависимость, используя только

groupId

и

artifactId

, и версия будет наследоваться

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
    </dependency>
   //...
</dependencies>

Более того, вы можете предоставить исключения для управления зависимостями в родительском

pom.xml

, чтобы определенные библиотеки не наследовались дочерними модулями:

<exclusions>
    <exclusion>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
    </exclusion>
</exclusions>

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

pom.xml

дочернего элемента:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.2.1.RELEASE</version>
</dependency>
  • Обратите внимание, что хотя дочерние модули наследуют от своего родительского проекта, родительский проект не обязательно имеет какие-либо модули, которые он объединяет. С другой стороны, родительский проект может также объединять проекты, которые не наследуются от него. **


6.4. Обновление субмодулей и построение проекта

Мы можем изменить тип

packaging

каждого подмодуля. Например, давайте изменим

packaging

модуля

webapp

на

WAR

, обновив файл

pom.xml

:

<packaging>war</packaging>

Теперь мы можем протестировать сборку нашего проекта с помощью команды

mvn clean install

. Выходные данные журналов Maven должны быть похожи на это:

----[INFO]Scanning for projects...[INFO]Reactor build order:[INFO]  parent-project[INFO]  core[INFO]  service[INFO]  webapp//.............[INFO]-----------------------------------------[INFO]Reactor Summary:[INFO]-----------------------------------------[INFO]parent-project .................. SUCCESS[2.041s][INFO]core ............................ SUCCESS[4.802s][INFO]service ......................... SUCCESS[3.065s][INFO]webapp .......................... SUCCESS[6.125s][INFO]-----------------------------------------
----


7. Заключение

В этой статье мы обсудили некоторые из наиболее популярных функций инструмента сборки Apache Maven.

Все примеры кода на Baeldung построены с использованием Maven, поэтому вы можете легко проверить наш

GitHub веб-сайт проекта

, чтобы увидеть различные конфигурации Maven.

Мы начнем с быстрого вступления, а затем перечислим преимущества его использования. После всего этого мы увидим процесс его установки, а затем несколько технических терминов, которые необходимы новичку. Итак, начнем!

Apache Maven — это программное обеспечение для управления и сборки проектов. Он основан на концепции объектной модели проекта (POM). Maven может управлять сборкой проекта, составлением отчетов и документацией из центральной части информации.

Apache Maven — это инструмент для сборки, и он выполняет эту задачу точно так же, как например Ant, который тоже является выдающимся инструментом для сборки. Это программный инструмент управления проектами, который дает новую концепцию объектной модели проекта (POM).

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

Apahe Maven

Зачем используется Maven?

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

Он работает на многих этапах, таких как добавление jar-файлов в библиотеку проекта, создание отчетов и выполнение тестовых примеров Junits, создание файлов Jar, War, Ear для проекта и многое другое.

Очень важным аспектом Maven является назначение хранилищ для управления файлами JAR.

Maven может также использоваться для создания и управления проектами, написанными на таких языках, как C #, ruby ​​и других.

Давайте посмотрим на следующие преимущества Maven.

  • Его конфигурация очень минимальная
  • Имеет управляющие зависимости
  • Автоматизация всего процесса
  • Он имеет возможность запускать JUnit и другие интеграционные тесты
  • Возможность управление плагинами, тестирование и разработка
  • Стандартная и унифицированная инфраструктура среди проектов

Maven

Настройка среды Maven

Установка Maven включает в себя следующие шаги:

  • Проверьте, установлена ​​ли в системе Java. если нет то установите его
  • Проверьте, установлена ​​ли переменная среды Java. Если нет, то установите его
  • Скачайте Maven
  • Распакуйте архив maven в одной месте системы
  • Теперь добавьте папку bin из каталога apache-maven-3.6.3 в переменную среды PATH и системную переменную.
  • Откройте командную строку и выполните команду mvn -v, чтобы подтвердить установку.

Вот и все.

Чтобы получить подробные инструкции по установке, следуйте приведенному ниже руководству на YouTube по настройке среды Maven, поскольку мы не хотим, чтобы эта статья была простой для чтения и скучной.

Данное руководство для начинающих, должно включать технические термины, связанные с MAVEN. Вот некоторые из них, которые очень важны:

Maven локальный репозиторий

Maven Local Repository — это набор, в котором Maven хранит все файлы jar проекта, библиотеки или зависимости. По умолчанию имя папки установлено на .m2, а путь находиться в LibrariesDocuments.m2.

Maven Центральный репозиторий

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

Maven POM

POM — это XML-файл объектной модели проекта, содержащий информацию о проекте и сведения о конфигурации, необходимые Maven для разработки проекта. Он содержит значения по умолчанию для большинства проектов. Некоторые из структур, которые могут быть определены в POM, — это зависимости проекта, плагины, которые могут быть выполнены, и, конечно, профили сборки.

Элементы, используемые в создании файла pom.xml:

  • project — Проект является корневым элементом файла pom.xml.
  • modelVersion — Означает версию модели POM, с которой вы работаете.
  • groupId — подразумевает идентификатор группы проекта. Он уникален, и чаще всего вы будете применять идентификатор группы, связанный с именем корневого пакета Java.
  • artifactId — используется для предоставления названия проекта, который вы собираете.
  • Version — этот элемент состоит из номера версии проекта. Если ваш проект был выпущен в различных версиях, тогда удобно представить версию вашего проекта.

Зависимость (Dependency)

Зависимости (Dependency) — это библиотеки, которые нужны проекту. Подобно jar-файлам Log4j, jar-файлам Apache Poi, Selenium Jars — это несколько библиотек, которые требуются для проекта. Зависимости в Maven pom.xml упоминаются так:

<dependencies>

      <dependency>
         <groupId>com.companyname.groupname</groupId>
         <artifactId>App-Core-lib</artifactId>
         <version>1.0</version>
      </dependency>

</dependencies>

Плагин Surefire

Плагин Surefire необходим во время фазы тестирования жизненного цикла сборки для реализации модульных тестов приложения. Он создает отчеты в двух разных форматах, таких как обычный текстовый файл, XML-файлы, а также в HTML-файлах. Даже если вы используете инфраструктуру Junits или TestNG для создания отчетов, этот плагин необходим для использования, поскольку он помогает Maven находить тесты.

Практическое применение Maven

Когда вы работаете над конкретным проектом Java, и у этого проекта много зависимостей, сборок, требований, то работа со всеми этими вещами вручную является чрезвычайно сложной и трудоемкой. Таким образом, использование некоторых инструментов, которые могут выполнить эти работы, действительно полезно.

А Maven — это такой инструмент управления сборкой, который может выполнять все такие вещи, как добавление зависимостей, использование пути к классам для проецирования, автоматическое создание файлов war и jar и много других вещей.

Также рекомендуем прочитать:

  1. Книги по языку программирования Java
  2. Топ-5 последних потрясающих фреймворков на Java
  3. Топ-9 Java EE фреймворков для создания корпоративных приложений
  4. Как бесплатно получить SSL-сертификат для сайта?

Maven — это инструмент для автоматической сборки проектов на основе описания их структуры в специальных файлах на языке POM (Project Object Model) — подмножестве XML.

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

Логотип системы сборки Apache Maven

Зачем разработчики используют Maven

Функциональность системы сборки Maven шире, чем компилятора исходного кода. В процессе работы приложения Apache Maven вызывает компилятор и при этом автоматически управляет зависимостями и ресурсами, например:

  • загружает подходящие версии пакетов;
  • размещает изображения, аудио- и видеофайлы в нужных папках;
  • подгружает сторонние библиотеки. 

Автоматическая сборка приложения особенно важна на этапах разработки, отладки и тестирования — Maven помогает собрать код и ресурсы в исполняемое приложение без IDE (среды разработки). При этом система сборки отличается гибкостью:

  • может использоваться в IDE — Eclipse, IntelliJ IDEA, NetBeans и других;
  • не зависит от операционной системы;
  • не требует установки — архив с программой можно распаковать в любой директории;
  • все необходимые параметры имеют оптимальные настройки по умолчанию;
  • упрощает организацию командной работы и документирование;
  • запускает библиотеки для модульного тестирования;
  • обеспечивает соблюдение стандартов;
  • имеет огромное количество плагинов и расширений.

Также существуют две другие системы сборки Java-приложений — Ant и Gradle, однако Maven пользуется наибольшей популярностью и является стандартом индустрии.

Установка и настройка среды Maven

Установочный файл системы сборки Apache Maven можно скачать с официального сайта. Программа займет около 10 Мб дискового пространства, но для создания локального репозитория потребуется не менее 500 Мб.

Для запуска системы на компьютере пользователя должен быть установлен пакет JDK, а в переменной окружения PATH указан путь к maven/bin. Если архив с Maven распаковали, предположим, в директорию C:Utils, то путь будет выглядеть так: C:Utilsmavenbin.

Чтобы установить переменную в Windows 10, нужно перейти в Панель управления Система Дополнительные параметры системы. Затем нажать Переменные среды, найти PATH и выбрать Изменить, после чего добавить путь C:Utilsmavenbin в конец строки.

Локальный репозиторий

Репозиторий — это место для хранения и обновления файлов проекта. Директория на компьютере разработчика, в которой Maven хранит все jar-файлы отдельного проекта, библиотеки и необходимые модули (зависимости), называется локальным репозиторием. По умолчанию он располагается в папке LibrariesDocuments.m2.

Центральный репозиторий

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

Maven POM

В среде Maven «собранные» проекты называются артефактами, а не приложениями или программами. Термин выбран потому, что готовый проект не всегда является исполняемым приложением — он может быть модулем, плагином или библиотекой.

Для описания структуры проектов Apache Maven применяет разновидность языка XML под названием POM (сокращение от Project Object Model, «объектная модель проекта»). Основные теги POM:

  • project базовый тег, содержит всю информацию о приложении;
  • modelVersion генерируется автоматически, текущая версия — 4.0.0;
  • groupId пакет, к которому принадлежит приложение, с добавлением имени домена;
  • artifactId уникальный ID артефакта;
  • version создается и обновляется автоматически, во время разработки к номеру версии добавляется суффикс -SNAPSHOT.

Информация, заключенная в тегах, является минимально необходимым описанием проекта (minimal POM), представленным в файле pom.xml. Пример POM-файла выглядит так:<project> <modelversion>4.0.0</modelversion> <groupid>com.sample.app</groupid> <artifactid>new-app</artifactid> <version>1.0-SNAPSHOT</version> </project>

Зависимости (Dependency)

Зависимостями разработчики называют сторонние библиотеки и модули, которые влияют на работоспособность программы. Maven обеспечивает автоматическое управление зависимостью — загружает модули и генерирует их описание в объектной модели проекта. В системе POM используются два тега — dependencies и dependency. Пример описания выглядит так:<dependencies> <dependency> <groupid> com.ourcompany.app </groupid> <artifactid>our-first-app</artifactid> <version>2.0</version> <type>war</type> <scope>runtime</scope> </dependency> <dependency> <groupid> com.ourcompany.app </groupid> <artifactid>our-second-app</artifactid> <version>1.0</version> <type>bar</type> <scope>runtime</scope> </dependency> </dependencies>

В нем тег <scope>runtime</scope> указывает на то, что зависимость относится к запуску приложения и не требуется для компиляции. В случае использования зависимости для компиляции тег имел бы вид <scope>compile</scope>, а для тестирования приложения — <scope>test</scope>.

Плагин Surefire для тестирования в системе Maven

Для тестирования модулей программы система сборки использует плагин Surefire, который можно загрузить с официального сайта. Отчеты о проверке модулей плагин сохраняет в двух форматах:

  • текст без форматирования .txt;
  • файл .xml.

Если разработчику нужны отчеты в HTML-формате, можно установить дополнительное расширение для Surefire — Maven Surefire Report Plugin. По умолчанию отчеты во всех форматах сохраняются в папке /target/surefire-reports/. Плагин Surefire способен выполнять тестирование проекта как самостоятельно, так и в интеграции с другими популярными фреймворками для проведения тестов Java-приложений, например TestNG и Junit.

Maven упрощает все этапы разработки и сборки

Архетипы и структура проектов

Архетипами в среде Maven называются шаблоны. Образцы шаблонов есть на официальном сайте проекта. С их помощью можно сгенерировать прототипы нескольких проектов — простого приложения, плагина, сайта. Список доступных архетипов получают, выполнив в консоли команду:

mvn archetype:generate

Один из стандартных шаблонов представляет собой традиционнуюпрограмму «Hello, world!». Чтобы скачать архетип в свой локальный репозиторий, нужно выполнить команду:

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

Скачивание первого шаблона может занять продолжительное время — это происходит потому, что система сборки проверяет доступные обновления и плагины. По умолчанию приложение называется my-app. Перейти в его корневую директорию можно с помощью команды:

cd my-app

Архетипы позволяют начинающим разработчикам быстро познакомиться с необходимой структурой Java-проектов. В директории my-app находятся папки:

src/main/java с исходным кодом проекта;

src/test/java с тестовым кодом.

Для сборки проекта выполните команду:

mvn package

По ней Maven запускает компиляцию артефакта в jar-файл. Готовую программу запускают командой:

java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App

В результате на экране появится приветствие:

Hello, world!

Intellij IDEA позволяет создавать и запускать проекты без использования консоли. Узнать, как это сделать, можно из видео.https://www.youtube.com/embed/pt3uB0sd5kY Title Работа с Intellij IDEA. Источник

Maven многократно упрощает процесс разработки и сборки на всех этапах — от структурирования проекта и тестирования кода до «упаковки» готового артефакта. Умение работать с системой сборки необходимо любому Java-разработчику. 

Понравилась статья? Поделить с друзьями:
  • Darkest dungeon стим руководство
  • Руководство по настройке операционной системы
  • Вопросы по модулю классное руководство
  • Руководство по библиотечному обслуживанию детей в россии 2019 г
  • Холи альфа инструкция по применению уколы внутримышечно взрослым