С описанием фреймворка maven можно познакомиться здесь. На этой странице рассматриваются наиболее распространенные плагины, используемые при сборке проекта. Список установленных на компьютере плагинов maven можно увидеть в директории $/repository/org/apache/maven/plugins приблизительно в таком виде, как на следующем скриншоте.
На странице рассмотрены следующие плагины с примерами :
buildnumber-maven-plugin — плагин генерации номера сборки;
Плагин создания проекта maven-archetype-plugin
Одним из самых первых плагинов, с которым приходится знакомиться или начинать новый проект, это maven-archetype-plugin. Данный плагин позволяет по определенному шаблону (archetype) сформировать структуру проекта. Примеры maven проектов для разнотипных приложений можно увидеть здесь.
Плагин компиляции maven-compiler-plugin
Самый популярный плагин, позволяющий управлять версией компилятора и используемый практически во всех проектах, это компилятор maven-compiler-plugin. Он доступен по умолчанию, но практически в каждом проекте его приходится переобъявлять. В простейшем случае плагин позволяет определить версию java машины (JVM), для которой написан код приложения, и версию java для компиляции кода. Пример использования :
В данном примере определена версия java-кода 1.7, на котором написана программа (source). Версия java машины, на которой будет работать программа, определена тегом . В теге указана кодировка исходного кода (UTF-8). По умолчанию используется версия java 1.3, а кодировка выбирается из операционной системы. Плагин позволяет указать путь к компилятору javac тегом .
Плагин maven-compiler-plugin имеет две цели :
compiler:compile — компиляция исходников, по умолчанию связана с фазой compile;
compiler:testCompile — компиляция тестов, по умолчанию связана с фазой test-compile.
Кроме приведёных настроек компилятор позволяет определить аргументы компиляции :
Плагин копирования ресурсов maven-resources-plugin
Перед сборкой проекта необходимо все ресурсы (файлы изображений, файлы .properties) скопировать в директорию target. Для этого используется плагин maven-resources-plugin. Пример использования плагина :
Тег определяет целевую директорию, в которую будет происходить копирование.
В данном примере maven должен положить в директорию target всё точно также, как и было в проекте. При копировании ресурсов можно использовать дополнительные возможности maven-resources-plugin, позволяющие вносить изменения в файлы свойств. Для этого используется тег , который при значении true предлагает плагину заглянуть во внутрь файла и при наличии определенных значений заменить их переменными maven’а. Файлы изображений не фильтруются. Поэтому ресурсы можно разнести по разным тэгам .
Дополнительно об использовании фильтрации для корректировки значений в файле свойств .properties можно почитать здесь.
Плагин maven-source-plugin позволяет включать в сборку проекта исходный код. Данная возможность особенно полезна, если создается многомодульная архитектура проекта, включающая различные файлы .jar, и требуется отладка отдельных частей. Пример использования maven-source-plugin :
outputDirectory — определение директории, в которую будут копироваться зависимости;
overWriteReleases — флаг необходимости перезаписывания зависимостей при создании релиза;
overWriteSnapshots — флаг необходимости перезаписывания неокончательных зависимостей, в которых присутствует SNAPSHOT;
overWriteIfNewer — флаг необходимости перезаписывания библиотек с наличием более новых версий.
В примере определен раздел с идентификатором copy-dependencies — копирование зависимостей. Плагин используется в фазе сборки , цель copy-dependencies. В разделе конфигурации configuration определен каталог, в который будут копироваться зависимости. Дополнительные параметры говорят о том, что перезаписываем библиотеки с наличием более новых версий, не перезаписываем текущие версии и не перезаписываем зависимости без окончательной версии (SNAPSHOT).
Плагин maven-dependency-plugin включает несколько целей, некоторые приведены ниже :
mvn dependency:analyze — анализ зависимостей (используемые, неиспользуемые, указанные, неуказанные);
mvn dependency:analyze-duplicate — определение дублирующиеся зависимостей;
mvn dependency:resolve — разрешение (определение) всех зависимостей;
mvn dependency:resolve-plugin — разрешение (определение) всех плагинов;
mvn dependency:tree — вывод на экран дерева зависимостей.
Плагин создания jar-файла maven-jar-plugin
Плагин maven-jar-plugin позволяет сформировать манифест, описать дополнительные ресурсы, необходимые для включения в jar-файл, и упаковать проект в jar-архив. Пример проектного файла pom.xml, описывающий настройку данного плагина :
В примере определена директория и манифест, включаемые в сборку. Тегом блокируется включение в сборку определенных файлов изображений.
Плагин maven-jar-plugin может создать и включить в сборку MANIFEST.MF самостоятельно. Для этого следует в секцию включить тег с опциями :
truelib/ru.company.AppMain
определяет необходимость добавления в манифест CLASSPATH;
позволяет дописывать префикс (в примере lib) перед каждым ресурсом;
указывает на главный исполняемый класс.
Определение префикса в позволяет размещать зависимости в отдельной папке.
Пример создания сборки (исполняемый jar-файл) с зависимостями библиотеки SWT можно посмотреть здесь.
Плагин тестирования maven-surefire-plugin
Плагин maven-surefire-plugin предназначен для запуска тестов и генерации отчетов по результатам их выполнения. По умолчанию на тестирование запускаются все java-файлы, наименование которых начинается с «Test» и заканчивается «Test» или «TestCase» :
**/Test*.java
**/*Test.java
**/*TestCase.java
Если необходимо запустить java-файл с отличным от соглашения наименованием, например Sample.java, то необходимо в проектный файл pom.xml включить соответствующую секцию с плагином maven-surefire-plugin.
Плагин maven-surefire-plugin содержит единственную цель surefire:test. Для разработки кодов тестирования можно использовать как JUnit, так и TestNG. Результаты тестирования в виде отчетов в форматах .txt и .xml сохраняются в директории $/target/surefire-reports.
Иногда приходится отдельные тесты исключать. Это можно сделать включением в секцию тега .
Чтобы запустить проект на тестирование необходимо выполнить одну из следующих команд :
mvn test mvn -Dmaven.surefire.debug test
Чтобы пропустить выполнение тестов на этапе сборки проекта, можно выполнить команду.
mvn clean package -Dmaven.test.skip=true
Также можно проигнорировать выполнение тестирования проекта включением в секцию тега
true
Плагин генерации номера сборки buildnumber-maven-plugin
Предположим, что нам нужно в манифест MANIFEST.MF нашего WEB-приложения и в файл свойств src/main/resources/app.properties положить номер сборки, который определяется переменной $ . Файл манифеста будем генерить автоматически. А в файл свойств проекта app.properties включим параметры, значения которых будут определяться на этапе сборки проекта :
В режиме выполнения программы (runtime) можно обращаться к данному файлу свойств для получения наименования приложения и номера версии сборки.
Для генерирования уникального номера сборки проекта используется плагин buildnumber-maven-plugin. Найти плагин можно в репозитории в директории $/repository/org/codehaus/mojo. Пример настройки плагина в проектном файле pom.xml :
В приведенном примере плагин запускается во время фазы жизненного цикла validate и генерирует номер версии $, который собирается из нескольких частей и определен тэгом . Каждая часть номера версии заключается в фигурные скобки и формируется согласно описанию MessageFormat языка Java. Каждой части соответствует тэг , указывающий, какое значение должно быть подставлено.
Если в pom.xml не настроена работа с SCM (Source Code Management) типа Subversion, Git и т.п., то при попытке генерации номера сборки будет получено сообщение об ошибке «The scm url cannot be null». В этом случае можно указать в pom.xml заглушку SCM.
Чтобы номер сборки генерировался независимо от подключения к SCM в настройках конфигурации плагина следует указать свойство revisionOnScmFailure равным true.
Теперь настроим плагин maven-war-plugin, чтобы номер версии поместить в MANIFEST.MF, который будет создаваться автоматически :
org.apache.maven.pluginsmaven-war-plugin2.6true $
Генерируемое значение, по-умолчанию, сохраняется в файле $/buildNumber.properties и имеет имя buildNumber. При необходимости данные параметры могут быть переопределены через свойства buildNumberPropertiesFileLocation и buildNumberPropertyName соответственно.
Чтобы определить значения в файле свойств src/main/resources/app.properties включим фильтрацию ресурсов в разделе :
src/main/resourcestrue .
Дополнительную информацию о фильтрации для корректировки значений в файле свойств *.properties можно почитать здесь.
После выполнения сборки проекта манифест MANIFEST.MF в файле .war будет иметь приблизительно следующий вид :
Чтобы в сервлете WEB-приложения прочитать версию сборки в файле MANIFEST.MF можно использовать следующий код :
import java.io.IOException; import java.util.Properties; . String version = "UNDEFINED"; Properties prop = new Properties(); try < prop.load(getServletContext().getResourceAsStream("/META-INF/MANIFEST.MF")); version = prop.getProperty("Implementation-Build"); >catch (IOException e) <> .
Maven surefire plugin для чего
Apache /
Maven /
Surefire /
Maven Surefire Plugin /
Introduction
| Last Published: 2023-12-09
Version: 3.2.3
Maven Surefire Plugin
Requirements: Maven 3.2.5 and JDK 1.8 or higher.
The Surefire Plugin is used during the test phase of the build lifecycle to execute the unit tests of an application. It generates reports in two different file formats:
Plain text files ( *.txt )
XML files ( *.xml )
By default, these files are generated in $/target/surefire-reports/TEST-*.xml .
The schema for the Surefire XML reports is available at Surefire XML Report Schema.
For an HTML format of the report, please see the Maven Surefire Report Plugin.
Goals Overview
The Surefire Plugin has only one goal:
surefire:test runs the unit tests of an application.
Usage
General instructions on how to use the Surefire Plugin can be found on the usage page. Some more specific use cases are described in the examples listed below. Additionally, users can contribute to the GitHub project.
In case you still have questions regarding the plugin’s usage, please have a look at the FAQ and feel free to contact the user mailing list. The posts to the mailing list are archived and could already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching the mail archive.
If you feel like the plugin is missing a feature or has a defect, you can file a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.
Examples
The following examples show how to use the Surefire Plugin in more advanced use cases:
Using TestNG
Using JUnit 5 Platform
Using JUnit
Using POJO Tests
Skipping Tests
Skip After Failure
Inclusions and Exclusions of Tests
Running a Single Test
Re-run Failing Tests
Class Loading and Forking
Debugging Tests
Using System Properties
Configuring the Classpath
Selecting Providers
Fork Options and Parallel Test Execution
Using Console Logs
Shutdown of Forked JVM
Run tests with Java 9
Run tests in Docker
Apache Maven Surefire Plugin, Maven Surefire Plugin, Apache, the Apache feather logo, and the Apache Maven Surefire Plugin project logos are trademarks of The Apache Software Foundation.
Maven surefire plugin для чего
Apache /
Maven /
Surefire /
Maven Surefire Plugin /
Usage
| Last Published: 2023-12-09
Version: 3.2.3
Usage
Best practice is to define the version of the Surefire Plugin that you want to use in either your pom.xml or a parent pom.xml :
The Surefire Plugin can be invoked by calling the test phase of the build lifecycle.
mvn test
Using Different Testing Providers
Tests in your test source directory can be any combination of the following:
TestNG
JUnit (3.8, 4.x or 5.x)
POJO
Which providers are available is controlled simply by the inclusion of the appropriate dependencies (i.e., junit:junit or junit:junit-dep for JUnit4, junit-jupiter-engine or junit-vintage-engine for JUnit5 and org.testng:testng 4.7+ for TestNG). Since this is required to compile the test classes anyway, no additional configuration is required.
Note that any normal Surefire integration works identically no matter which providers are in use — so you can still produce a Cobertura report and a Surefire results report on your project web site for your TestNG tests, for example.
The POJO provider above allows you to write tests that do not depend on either of JUnit and TestNG. It behaves in the same way, running all test* methods that are public in the class, but the API dependency is not required. To perform assertions, the JDK 1.4 assert keyword can be used. See Using POJO Tests for more information.
All of the providers support the Surefire Plugin parameter configurations. However, there are additional options available if you are running TestNG tests (including if you are using TestNG to execute your JUnit tests, which occurs by default if both are present in Surefire).
See Using TestNG for more information.
Apache Maven Surefire Plugin, Maven Surefire Plugin, Apache, the Apache feather logo, and the Apache Maven Surefire Plugin project logos are trademarks of The Apache Software Foundation.
Краткое руководство по плагину Maven Surefire
В этом руководстве демонстрируется плагин surefire , один из основных плагинов инструмента сборки Maven. Обзор других основных плагинов см. в этой статье .
2. Цель плагина
Мы можем запустить тесты проекта с помощью плагина surefire . По умолчанию этот плагин генерирует отчеты в формате XML в каталоге target/surefire-reports .
У этого плагина только одна цель — протестировать . Эта цель привязана к тестовой фазе жизненного цикла сборки по умолчанию, и команда mvn test выполнит ее.
3. Конфигурация
Плагин surefire может работать с тестовыми фреймворками JUnit и TestNG. Независимо от того, какой фреймворк мы используем, верный огонь ведет себя одинаково.
По умолчанию surefire автоматически включает все тестовые классы, имя которых начинается с Test или заканчивается на Test , Tests или TestCase .
Однако мы можем изменить эту конфигурацию с помощью параметров exclude и include : «
