Как собрать простейшую java программу с помощью maven

Содержание:

Сборка Java кода

Теперь все готово для сборки проекта Maven’ом. Вы можете выполнить несколько этапов жизненного цикла сборки,
включая компиляцию кода, создание библиотеки пакета(такого, как JAR-файл) и установку библиотеки в
локальный репозиторий Maven зависимостей.

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

Этим вы запустите Maven, передав ему указание на выполнение задачи compile. Когда он закончит,
вы должны найни скомпилированные .class файлы в target/classes директории.

Вряд ли вы захотите распостранять или работать напрямую с .class файлами, поэтому
вам полее подойдет выполнение задачи package:

Задача package включает компиляцию вашего Java кода, запуск тестов, а в конце упаковывает
в JAR-файл в target директории. Название JAR-файла будет основано на
и . К примеру, с минимальным pom.xml(см. выше), JAR-файл будет иметь
название gs-maven-initial-0.1.0.jar.

Если вы изменили значение с «jar» на «war», то результатом будет
WAR-файл в target директории вместо JAR-файла.

Maven также хранит репозиторий зависимостей на вашей локальной машине(обычно в .m2/repository
директории в вашей домашней папке) для быстрого доступа к зависимостям проекта. Если вы хотите
добавить JAR-файл вашего проекта в локальный репозиторий, тогда вам необходимо выполнить задачу :

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

Говоря о зависимостях, пришло время объявлять зависимости в Maven сборке.

Apache Maven Deploy Plugin

Guide to creating and running a jar file in java

The deploy plugin is primarily used during the deploy phase, to add your artifact(s) to a remote repository for sharing with other developers and projects. This is usually done in an integration or release environment. It can also be used to deploy a particular artifact (e.g. a third party jar like Sun’s non redistributable reference implementations).

As a repository contains more than the artifacts (POMs, the metadata, MD5 and SHA1 hash files…), deploying means not only copying the artifacts, but making sure all this information is correctly updated. It’s the reponsibility of the deploy plugin.

To work, the deployment will require:

information about the repository: its location, the transport method used to access it (FTP, SCP, SFTP…) and the optional user specific required account information
information about the artifact(s): the group, artifact, version, packaging, classifier…
a deployer: a method to actually perform the deployment. This can be implemented as a wagon transport (making it cross-platform), or use a system specific method.

The information will be taken from the implied (or specified) pom and from the command line. The settings.xml file may also be parsed to retrieve user credentials.

Goals Overview

The deploy plugin has 2 goals:

deploy:deploy is used to automatically install the artifact, its pom and the attached artifacts produced by a particular project. Most if not all of the information related to the deployment is stored in the project’s pom.
deploy:deploy-file is used to install a single artifact along with its pom. In that case the artifact information can be taken from an optionally specified pomFile, but can be completed/overriden using the command line.

Major Version Upgrade to version 3.0.0

Please note that the following parameter has been completely removed from the plugin configuration:

uniqueVersion

As of Maven 3, snapshot artifacts will always be deployed using a timestamped version.

Usage

General instructions on how to use the Deploy Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

If you feel like the plugin is missing a feature or has a defect, you can fill 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

To provide you with better understanding on some usages of the deploy plugin, you can take a look into the following examples:

Project Deployment:

Deployment with FTP
Deployment with external SSH

File Deployment:

Disable the generation of pom
Deploy an artifact with a customed pom
Deploy an artifact with classifier
Disable timestamps suffix in an artifact
Deploy an artifact in legacy layout

Single Project Setup

Как сгенерировать случайное число в java

This can look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
</project>

This is of course a simple situation where we use only for brevity to show the general course.

Based on the above pom you can build your project using:

mvn clean package

But wait there is a problem? Which version will the artifacts have? So you need to define the version for your artifacts. The first possibility is to use the command line like this:

mvn -Drevision=1.0.0-SNAPSHOT clean package

This will become cumbersome over the time. So the other solution for this is to simply use a property inside the pom file which looks like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>
</project>

So now you can simply call Maven as usual like .

You can of course change the version via the command line like this:

mvn -Drevision=2.0.0-SNAPSHOT clean package

Of course you can use the file for this.

A note about the used properties. You can only use those named , and/or and not other named properties like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-${buildNumber}-SNAPSHOT</revision>
  </properties>
</project>

The above example will not work as expected. If you like to have more flexibility you can use a combination of the different properties like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}${sha1}${changelist}</version>
  ...
  <properties>
    <revision>1.3.1</revision>
    <changelist>-SNAPSHOT</changelist>
    <sha1/>
  </properties>
</project>

If you like to make a version this can simply being achieved by using this:

mvn -Drevision=2.0.0 clean package

Another usage example can be to make a release which can be done via (version 1.3.1):

mvn -Dchangelist= clean package

Or if you like to make a release with another version:

mvn -Drevision=2.7.8 -Dchangelist= clean package

Multi Module Setup

Изучаем java: сравнение строк

So now let us take a look into a situation where we have a multi module build. We have a parent pom and one or more children. The parent pom will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

The child will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <version>${revision}</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-child</artifactId>
   ...
</project>

Dependencies

In a multi module build you have often the case that you define dependencies between module(s). The usual way of defining dependencies and their appropriate versions has been to use and this has not been changed.

So the correct way to do such things can be seen in the following example:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

The child will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <version>${revision}</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-child</artifactId>
   ...
  <dependencies>
    <dependency>
      <groupId>org.apache.maven.ci</groupId>
      <artifactId>child2</artifactId>
      <version>${project.version}</version>
    </dependency>
  </dependencies>
</project>

Use the Compiler Plugin

We can specify the desired Java version in the compiler plugin.

2.1. Compiler Plugin

The first option is setting the version in compiler plugin properties:

The Maven compiler accepts this command with –target and –source versions. If we want to use the Java 8 language features, the –source should be set to 1.8.

Also, for the compiled classes to be compatible with JVM 1.8, the –target value should be 1.8.

The default value for both of them is the 1.6 version.

Alternatively, we can configure the compiler plugin directly:

The maven-compiler-plugin also has additional configuration properties that allow us to have more control over the compilation process beyond -source and -target versions.

2.2. Java 9 and Beyond

Furthermore, starting from the JDK 9 version, we can use a new -release command-line option. This new argument will automatically configure the compiler to produce class files that will link against the implementation of the given platform version.

By default, the -source and -target options don’t guarantee a cross-compilation.

This means that we cannot run our application on older versions of the platform. Additionally, to compile and run the programs for older Java versions, we also need to specify -bootclasspath option.

To cross-compile correctly, the new -release option replaces three flags: -source, -target and -bootclasspath.

After transforming our examples, we can declare the following for the plugin properties:

And for the maven-compiler-plugin starting from the 3.6 version, this is what we can write:

Notice that we can add the Java version in a new <release> attribute. In this example, we compile our application for Java 7.

What’s more, we don’t need a JDK 7 installed in our machine. Java 9 already contains all the information for linking the new language features with JDK 7.

Описание Maven

Maven — один из самых популярных сборщиков для Java. Для чего его можно использовать:

Сборка Java проекта с подтягиванием зависимостей.
Создание jar.
Автоматически сгенерировать сопроводительную документации для кода на основе комментариев.
Создание дистрибутива.

Если проект java достаточно простой, можно собрать его вручную в командной строке. При больших объемах проекта такую команду записывают в bat/sh скрипт.

Структура проекта описывается через файл pom.xml (POM — Project Object Model), он должен лежать в корневой папке проекта.

Главным объектом Maven является артефакт (любая библиотека, хранящаяся в репозитории, зависимости и плагины).

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

Плагины используются самим Maven при сборке проекта или других целей (деплоймент, создание файлов проекта для Eclipse и др.).

Архетип — стандартная организация файлов и каталогов, используемая в разных проектах (веб, swing-проекты, тесты). То есть Maven знает как обычно строятся проекты разных видов и в соответствии с выбранным архетипом создает структуру файлов и каталогов.

Название артефакта состоит из названия группы, собственного названия и версии. Например, Spring в среде Maven будет иметь название:

org.springframework.spring:2.5.5.

Последний домен — artifactId, все что перед ним — groupId.

Default build lifecycle

Запустим сборку, указав фазу install:

mvn install

Обратите внимание, что pom.xml практически пустой – в нем не перечислены никакие фазы и goals, они все привязаны по умолчанию к сборке jar-файла:

<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>ru.sysout</groupId>
	<artifactId>example-maven-project</artifactId>
	<version>1.0</version>
</project>

При этом в pom.xml даже не указано, что надо собрать jar-файл – этот формат также подразумевается по умолчанию.

Вывод в консоль показывает, какие плагины и голы выполняются при сборке:

 --- maven-resources-plugin:2.6:resources (default-resources) @ example-maven-project ---
 Using platform encoding (Cp1251 actually) to copy filtered resources, i.e. build is platform dependent!
 Copying 0 resource
 
 --- maven-compiler-plugin:3.1:compile (default-compile) @ example-maven-project ---
 Nothing to compile - all classes are up to date
 
 --- maven-resources-plugin:2.6:testResources (default-testResources) @ example-maven-project ---
 Using platform encoding (Cp1251 actually) to copy filtered resources, i.e. build is platform dependent!
 skip non existing resourceDirectory C:\Code\sysout\example-maven-project\src\test\resources
 
 --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ example-maven-project ---
 No sources to compile
 
 --- maven-surefire-plugin:2.12.4:test (default-test) @ example-maven-project ---
 
 --- maven-jar-plugin:2.4:jar (default-jar) @ example-maven-project ---
 Building jar: C:\Code\sysout\example-maven-project\target\example-maven-project-1.0.jar
 
 --- maven-install-plugin:2.4:install (default-install) @ example-maven-project ---
 Installing C:\...\.m2\repository\ru\sysout\example-maven-project\1.0\example-maven-project-1.0.jar
 Installing C:\...\.m2\repository\ru\sysout\example-maven-project\1.0\example-maven-project-1.0.pom
 ------------------------------------------------------------------------
 BUILD SUCCESS

Как видно, по очереди выполняется:

копирование папки ресурсов main\resources
компиляция исходников из папки main\java
копирование тестовых ресурсов test\resources
компиляция исходников из папки test\java
далее происходит выполнение тестов
упаковка в jar и
копирование jar файла в .m2 папку на локальном компьютере.

Есть в жизненном цикле еще фаза deploy – развертывание на сервер, эта последняя фаза тут не выполнялась.

Жизненный цикл (lifecycle) сборки – это последовательность фаз (phases).

Выполнение предыдущих фаз

Обратите внимание, что мы указали одну фазу install, но выполняется целый жизненный цикл со всеми предыдущими фазами, фаза install в этом цикле последняя. Чтобы только скопировать ресурсы и скомпилировать проект, выполняем:

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

mvn compile

Чтобы, помимо этого, выполнить тесты и упаковать проект в jar, выполняем:

mvn package

(при этом выполнится компиляция и другие предваряющие package фазы).

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

mvn deploy

Все предыдущие фазы, включая install, также при этом выполнятся. В pom.xml при этом должна быть указана конфигурация с данными сервера, куда деплоить проект.

В документации указана очередность фаз, она задана заранее. Там же указаны какие именно плагины и goals по умолчанию выполняются в каких фазах. Мы можем перезаписать или добавить свое действие к определенный фазе.

Попробуем добавить свое действие к двум фазам.

Apache Maven Resources Plugin

The Resources Plugin handles the copying of project resources to the output directory. There are two different kinds of resources: main resources and test resources. The difference is that the main resources are the resources associated to the main source code while the test resources are associated to the test source code.

Thus, this allows the separation of resources for the main source code and its unit tests.

Starting with version 2.3 this plugin uses the Maven Filtering shared component for filtering resources.

Goals Overview

The Resources Plugin copies files specified by Resource elements, to an output directory. The three variations below only differ in how the resource and output directory elements are specified or defaulted. The Resources Plugin has three goals:

resources:resources copies the resources for the main source code to the main output directory.

This goal usually executes automatically, because it is bound by default to the process-resources life-cycle phase. It always uses the project.build.resources element to specify the resources, and by default uses the project.build.outputDirectory to specify the copy destination.
resources:testResources copies the resources for the test source code to the test output directory.

This goal usually executes automatically, because it is bound by default to the process-test-resources life-cycle phase. It always uses the project.build.testResources element to specify the resources, and by default uses the project.build.testOutputDirectory to specify the copy destination.
resources:copy-resources copies resources to an output directory.

This goal requires that you configure the resources to be copied, and specify the outputDirectory.

Usage

General instructions on how to use the Resources Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

Examples

The following examples show how to use the Resources Plugin in more advanced use cases:

Specifying a character encoding scheme
Specifying resource directories
Filtering
Including and excluding files and directories
Escape filtering
Copy resources
Binaries filtering
Custom resources filters

Создание приложения из архетипа

На сайте http://maven.apache.org/guides/introduction/introduction-to-archetypes.html перечислены основные архетипы приложений, но несложно создать свой или найти более специфичный .

Для примера если нам нужно веб-приложение, находим подходящий архетип maven-archetype-webapp. В командной строке в нужном каталоге вводим команду Maven:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

Теперь можем видеть наглядную структуру каталогов с говорящими названиями:

java — тут будут классы
webapp — страницы веб-приложения
resources — ресурсы
test — unit-тесты

Какие еще есть жизненные циклы Maven

Хотя в работе чаще используется default lifecycle, о котором мы говорили выше, он не единственный.

Всего жизненных циклов у Maven определено три:

default – этот цикл отвечает за развертывание проекта (и все предыдущие, предваряющие развертывание действия).
clean – отвечает за удаление файлов, оставшихся с предыдущей сборки. Удаляет папку target.
site – отвечает за создание документации.

mvn clean install

Довольно часто указывают две фазы подряд:

mvn clean install

Да, это фазы, но они принадлежат разным циклам. Тут запускается два цикла по очереди – сначала цикл clean, а затем цикл default.

Фаза clean не входит в default цикл. Фаза clean – это часть одноименного цикла clean.

Мы не можем указать, например:

mvn validate install

Это фазы из одного и того же цикла default, они не могут быть выдернуты из цикла и выполнены вне его (помните правило выполнения всех предыдущих фаз).

Так что хотя многие и считают, что в примере mvn clean install указаны некоторые две выбранные фазы одного цикла, это ложная догадка, на самом деле тут выполняются два цикла, а не две фазы.

Зависимости и репозитории.

Большинство популярных библиотек находятся в центральном репозитории , поэтому их можно сразу прописывать в раздел dependencies pom-файла.

Например, чтобы подключить Spring Framework нужно определить зависимость:

…

<groupId>org.springframework</groupId>

<artifacrId>spring</artifactId>

</dependency>

</dependencies>

Можно не указывать версию, тогда Maven возьмет последний вариант, но рекомендуется это делать.

Специфические вещи не находятся в центральном репозитории и нужно в таких случаях указать репозиторий вручную. К примеру, добавим зависимость JSF-фреймворка ajax-компонентов JBoss RichFaces.

С зависимостями все просто:

<groupId>org.richfaces.ui>/groupId>

<artifactId>richfaces-ui</artifactId>

</dependency>

</dependencies>

А репозиторий JBoss нужно прописать вручную либо в файле setting.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> </url> <layout>default</layout> </repository> </repositories>

Обычно на сайтах крупных проектов пишут все что нужно для встраивания их библиотеки в проект на основе Maven.

Apache Maven Install Plugin

The Install Plugin is used during the install phase to add artifact(s) to the local repository. The Install Plugin uses the information in the POM (groupId, artifactId, version) to determine the proper location for the artifact within the local repository.

The local repository is the local cache where all artifacts needed for the build are stored. By default, it is located within the user’s home directory (~/.m2/repository) but the location can be configured in ~/.m2/settings.xml using the <localRepository> element.

Goals Overview

The Install Plugin has 3 goals:

install:install is used to automatically install the project’s main artifact (the JAR, WAR or EAR), its POM and any attached artifacts (sources, javadoc, etc) produced by a particular project.
install:install-file is mostly used to install an externally created artifact into the local repository, along with its POM. In that case the project information can be taken from an optionally specified pomFile, but can also be given using command line parameters.
install:help displays help information on maven-install-plugin.

Important Note for Version 3.0.0+

The install:install goal does not support creating checksums anymore via -DcreateChecksum=true cause this option has been removed. Details can be found in MINSTALL-143.

Usage

General instructions on how to use the Install Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

Examples

To provide you with better understanding on some usages of the Maven Install Plugin, you can take a look into the following examples:

Installing a Custom POM
Generating a Generic POM
Creating Checksums
Updating Release Info
Installing an Artifact to a Specific Local Repository Path
Installing Secondary Artifacts

Feature Summary

The following are the key features of Maven in a nutshell:

Simple project setup that follows best practices — get a new project or module started in seconds
Consistent usage across all projects — means no ramp up time for new developers coming onto a project
Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
Able to easily work with multiple projects at the same time
A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for real-time availability of their latest releases
Extensible, with the ability to easily write plugins in Java or scripting languages
Instant access to new features with little or no extra configuration
Ant tasks for dependency management and deployment outside of Maven
Model based builds: Maven is able to build any number of projects into predefined output types such as a JAR, WAR, or distribution based on metadata about the project, without the need to do any scripting in most cases.
Coherent site of project information: Using the same metadata as for the build process, Maven is able to generate a web site or PDF including any documentation you care to add, and adds to that standard reports about the state of development of the project. Examples of this information can be seen at the bottom of the left-hand navigation of this site under the «Project Information» and «Project Reports» submenus.
Release management and distribution publication: Without much additional configuration, Maven will integrate with your source control system (such as Subversion or Git) and manage the release of a project based on a certain tag. It can also publish this to a distribution location for use by other projects. Maven is able to publish individual outputs such as a JAR, an archive including other dependencies and documentation, or as a source distribution.
Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project’s clients can use to download any JARs required for building your project from a central JAR repository much like Perl’s CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with.

Плагины

Плагины-это такие же артефакт, как и зависимости, поэтому описываются практически так же.

Вместо раздела dependencies-plugins, dependency-plugin, repositories-pluginRepositories, repository-pluginRepository.

Плагинами maven делает все, даже сборку проекта.

Настройка плагина ля создания проекта для Eclipse с использованием WTP ver. 2.0.

В разделе plugins файла pom.xml прописываем плагин:

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-eclipse-plugin</artifactId>

</configuration>

</plugin>

Теперь идем в командную строку и выполняем:

mvn eclipse:eclipse

Ждем пока Maven найдет все библиотеки в репозитории или скачает их и теперь Maven-проект можно открыть как проект Eclipse.

Однако плагины довольно легко найти, например по запросу «maven tomcat plugin«.

Заключение:

Maven, в отличие от Ant, описывает конечную структуру проекта, а не пути к ее достижению.

Как соотносятся phases и goals

Сборку с помощью Maven можно сравнить с обедом из нескольких блюд: в нем есть закуска, первое блюдо, второе блюдо, напиток и десерт – всё это фазы (phases), а все вместе – жизненный цикл. Второе блюдо может быть котлетой, а может рыбой. Конкретика задается с помощью goal (конкретная команда конкретного плагина). Например, на фазе compile по умолчанию выполняется compiler:compile – это goal с названием compile плагина compiler. Эта команда компилирует исходники. А десерт может быть шарлоткой, это тоже конкретный goal, например deploy:deploy фазы deploy.

К каждой фазе можно привязать несколько голов, а можно ни одного – тогда фаза просто пропускается при сборке.

Сложность состоит в том, что набор умолчаний в Maven велик – согласно документации, в жизненном цикле много зарезервированных , в которых ничего не выполняется (например, фаза validate). Эти фазы подразумевают какой-то смысл, но зарезервированы на тот случай, если программист захочет к ним привязать какое-то свое действие.
Конкретно на фазе validate должна проверяться корректность проекта, но как именно, решает программист, если ему это надо. (А если не надо, фаза validate пропускается). Ниже мы попробуем привязать к этой фазе простейшее действие.

Есть также фазы, которые, наоборот, выполняются по умолчанию – например, фаза compile. К ней по умолчанию привязан свой плагин и goal, как уже упоминалось выше.

Узнать, что именно происходит при сборке, можно, например, запустив сборку – все goals выведутся в консоль.

Можно также вывести все goals данной фазы так:

mvn help:describe -Dcmd=<фаза>

Попробуем запросить все goal фазы compile:

mvn help:describe -Dcmd=compile

Ответ такой:

compile' is a phase corresponding to this plugin:
org.apache.maven.plugins:maven-compiler-plugin:3.6:compile

То есть на фазе compile по умолчанию выполняется maven-compiler-plugin. Через двоеточие указана goal, она называется compile.

Apache Maven Help Plugin

The Maven Help Plugin is used to get relative information about a project or the system. It can be used to get a description of a particular plugin, including the plugin’s goals with their parameters and component requirements, the effective POM and effective settings of the current build, and the profiles applied to the current project being built.

Goals Overview

The Help Plugin has 7 goals:

help:active-profiles lists the profiles which are currently active for the build.
help:all-profiles lists the available profiles under the current project.
help:describe describes the attributes of a Plugin and/or a Mojo (Maven plain Old Java Object).
help:effective-pom displays the effective POM as an XML for the current build, with the active profiles factored in. If verbose, a comment is added to each XML element describing the origin of the line.
help:effective-settings displays the calculated settings as an XML for the project, given any profile enhancement and the inheritance of the global settings into the user-level settings.
help:evaluate evaluates Maven expressions given by the user in an interactive mode.
help:system displays a list of the platform details like system properties and environment variables.

Major Version Upgrade to version 3.0.0

Please note that the goal expressions has been completely removed from the plugin. All the Maven expressions that are supported as plugin parameters are available in the Javadoc of the PluginParameterExpressionEvaluator class.

Usage

General instructions on how to use the Help Plugin can be found on the usage page. Some more specific use cases are described in the examples given below. Last but not least, users occasionally contribute additional examples, tips or errata to the plugin’s wiki page.

Examples

To provide you with better understanding on some usages of the Help Plugin, you can take a look into the following example(s):

Configuring Describe Goal