Краткое изложение боя Maven

карта разума

maven

Maven и сборка

Что такое Мавен

Перевод: накопление знаний, эксперты, эксперты. Кроссплатформенный инструмент управления проектами. Проект с открытым исходным кодом организации Apache. В основном он обслуживает построение проекта, управление зависимостями и управление информацией о проекте на основе платформы Java.

Подобно yum и apt на платформе Linux и npm во внешнем интерфейсе. Maven ранее был известен как Ant. В настоящее время исходный код tomcat создается и управляется с помощью Ant. Более продвинутые инструменты включают проекты Gradle и Spring.

что такое сборка

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

Предполагая, что у нас сейчас нет Maven, компиляция, запуск модульных тестов, упаковка и т. д. — это отдельные шаги, которые необходимо интегрировать вручную. Что нам нужно сделать с Maven, так это использовать Maven для настройки проекта, а затем ввести простые команды (mvn clean, mvn package и т. д. или напрямую нажать кнопку), чтобы построение приложения могло быть похоже на полностью автоматический конвейер. , все утомительные шаги могут быть выполнены.

Maven — отличный инструмент сборки, а не просто инструмент сборки:

Управляйте трехсторонними библиотеками классов: предоставляйте зависимости импорта системы координат (вводные координаты автоматически загружают зависимости) и автоматически решайте сложные проблемы с зависимостями (несоответствия версий, конфликты версий, раздутые зависимости и т. д.), а также предоставляйте бесплатный центральный репозиторий зависимостей для всех разработчиков.
Управляйте информацией о проекте, которая в противном случае была бы разбросана по разным местам, включая описания проектов, разработчиков, лицензии и многое другое.
Механизм плагина. Разработчики могут настраивать плагины для реализации сложных требований сборки.

К этому моменту у вас должно сложиться предварительное впечатление о Maven. Давайте посмотрим, как использовать Maven.

Скелет проекта

Чтобы создать проект с помощью Maven, вы должны следовать некоторым соглашениям Maven. Ниже приведен стандартный проект Maven.скелет:

pom: объектная модель проекта

根目录：工程名
|---src：源码
|---|---main:主程序
|---|---|---java：主程序代码路径
|---|---|---resource：主程序配置文件路径
|---|---test：测试
|---|---|---java：测试代码路径
|---|---|---resource：测试配置文件路径
|---pom.xml：maven 配置文件

Простая демонстрация

## 1. 使用 archetype 命令生成 maven 简单骨架
mvn archetype:generate -DarchetypeCatalog=internal

## 2. 编译当前生成的项目
mvn compile

## 3. 使用其他命令
mvn test-compile  
mvn package  
mvn clean 
mvn install
mvn depoly 暂时不演示

Сборка идет медленно:blog.CSDN.net/coder Угадайте, что...
Команда mvn install объединяет ситуацию с China Merchants Bank, чтобы продемонстрировать

Координаты и зависимости

что такое координаты

Аналогия с плоской геометрией в математике, координаты (x, y), любая координата может однозначно идентифицировать точку на плоскости. Эта точка соответствует файлам maven: .jar, .war и другим файлам. Maven использует такие элементы, как groupId, ArtifactId, версия, упаковка и классификатор, для формирования собственных координат и определяет набор таких правил.Пока предоставлены правильные элементы координат, Maven может найти соответствующие артефакты.

Координатный элемент:

groupId: определяет фактический проект, к которому принадлежит текущий проект Maven.
artifactId: определяет проект Maven (модуль) в реальном проекте.
packaging: определяет, как упаковываются проекты Maven. баночка, война, пом. По умолчанию баночка.
version: определяет текущую версию проекта Maven.
classifier: различать артефакты с разным содержимым, созданные на основе одного и того же артефакта.

сценарии использования классификатора

Различать пакеты на основе разных версий JDK

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <version>2.2.2</version>  
    <classifier>jdk13</classifier>    
    <!--<classifier>jdk15</classifier>-->
</dependency>

Различать различные компоненты проекта

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <version>2.2.2</version>  
    <classifier>jdk15-javadoc</classifier>    
    <!--<classifier>jdk15-sources</classifier>  -->
</dependency>

Имена и координаты артефактов соответствующие, общее правило такое: идентификатор_артефакта-версия[-классификатор].упаковка.

объявление зависимости

<dependencies>
    <dependency>
        <groupId></groupId>
        <artifactId></artifactId>
        <version></version>
        <type></type>
        <optional></optional>
        <exclusions>
            <exclusion>
                <artifactId></artifactId>
                <groupId></groupId>
            </exclusion>
            ...
        </exclusions>
    </dependency>
    ...
</dependencies>

идентификатор группы, идентификатор артефакта, версия: базовые координаты зависимости.
type: Тип зависимости, соответствующий упаковке проекта, вообще не нужно объявлять.
scope: Область зависимостей, которая будет подробно объяснена позже.
optional: отметить, является ли зависимость необязательной.
exclusions: Используется для исключения транзитивных зависимостей.

Область зависимости

compile: скомпилировать область зависимости

Если не указано,дефолтИспользуйте эту область зависимости. Он действителен для всех трех путей к классам: compile, test и run. Например: пружинный сердечник.

test: тестовая область зависимости

Он действителен только для пути к классам теста, он нужен только при компиляции и запуске теста, он не будет введен при упаковке. Например: Юнит.

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

Допустимо для пути к классам компиляции и тестирования, но не во время выполнения. Например: servlet-api требуется при компиляции и тестировании проекта, но в реальной работе контейнер уже предоставлен, и нет необходимости в повторных обращениях со стороны maven.

время выполнения: область зависимости времени выполнения

Допустимо для пути к классам для тестирования и запуска, но не при компиляции основного кода. Например: пакет реализации драйвера JDBC. Специальный драйвер JDBC требуется только при выполнении тестов или запуске проекта.

system: область системных зависимостей

Точно так же, как предоставленная область зависимостей, но при использовании этой области необходимо явно указать путь к зависимому файлу через элемент systemPath. Поскольку такие зависимости не разрешаются через репозиторий maven и часто привязаны к нативной системе, что может сделать сборку непереносимой, их следует использовать с осторожностью. Элемент systemPath может ссылаться на такие переменные среды, как:

  <dependencies>
    <dependency>
      <groupId>javax.sql</groupId>
      <artifactId>jdbc-stdxt</artifactId>
      <version>2.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/lib/rt.jar</systemPath>
    </dependency>
  </dependencies>

import: область импорта зависимостей

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-framework-bom</artifactId>
            <version>4.3.16.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Механизмы зависимости и особенности

транзит зависимости

A->B(компиляция): первая прямая зависимость
B->C(компилировать): вторая прямая зависимость
A->C(компиляция): транзитивные зависимости

При настройке в А

<dependency>  
    <groupId>com.B</groupId>  
    <artifactId>B</artifactId>  
    <version>1.0</version>  
</dependency>

Пакет C автоматически импортируется.

Объем транзитивных зависимостей показан на следующей диаграмме:

传递性依赖

зависимость от посредничества

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

Принцип ближайшего пути первым

A->B->C->X(1.0)
A->D->X(2.0)

Поскольку можно импортировать только одну версию пакета, выберите импорт X(2.0) по кратчайшему пути.

первый декларант первый

A->B->Y(1.0)
A->C->Y(2.0)

В это время, поскольку длина зависимого пути одинакова, приоритет имеет первый декларант. При одинаковой длине пути, если зависимость B объявлена в файле POM до зависимости C, тогда будет импортирован Y (1.0). Для тестирования можно использовать следующие зависимости:

<dependencies>
    <dependency>
      <groupId>org.apache.httpcomponents</groupId>
      <artifactId>httpclient</artifactId>
      <version>4.4.1</version>
      <exclusions>
        <exclusion>
          <groupId>commons-codec</groupId>
          <artifactId>commons-codec</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.apache.poi</groupId>
      <artifactId>poi</artifactId>
      <version>3.9</version>
      <exclusions>
        <exclusion>
          <groupId>commons-codec</groupId>
          <artifactId>commons-codec</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.10</version>
    </dependency>

</dependencies>

Вот немного нужнообращать вниманиесм. следующие зависимости:

<dependencies>
    <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.11</version>
    </dependency>

    <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.10</version>
    </dependency>
</dependencies>

В соответствии с двумя принципами ожидаемый результат должен заключаться в том, что сборка версии 1.11 будет зависеть от нее. Но фактический результат зависит от версии 1.10. Какие! Разве это не нарушение первого принципа определения посредничества зависимостей maven? Похожие вопросы от пользователей сети:stackoverflow.com/questions/4…....

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

Ссылаться на:maven.apache.org/plugins/имя av…

необязательные зависимости

A->B, B->X (необязательно), B->Y (необязательно). Проект A зависит от проекта B, который зависит от проектов X и Y. Теоретически проект A будет зависеть от проектов B, X и Y. Однако две зависимости X и Y могут быть взаимоисключающими для B. Например, B является пакетом изоляции базы данных и поддерживает несколько баз данных, MySQL и Oracle.При построении проекта B требуется поддержка этих двух баз данных, но при использовании этого инструментария будет полагаться только на одну базу данных. На этом этапе вам нужно объявить X и Y в качестве необязательных зависимостей в pom-файле проекта B следующим образом:

<dependency>  
    <groupId>com.X</groupId>  
    <artifactId>X</artifactId>  
    <version>1.0</version>  
    <optionnal>true</optionnal>
</dependency>

<dependency>  
    <groupId>com.Y</groupId>  
    <artifactId>Y</artifactId>  
    <version>1.0</version>  
    <optionnal>true</optionnal>
</dependency>

После использования дополнительной идентификации элемента это повлияет только на текущий проект B. Когда другие проекты зависят от проекта B, ни одна из этих двух зависимостей не будет передана. Проект A зависит от проекта B. Если реальной базой данных приложения является X, то зависимость от X должна быть явно объявлена в файле A pom.

склад

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

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

Например, для повторного использования, если у вас есть упакованный jar-файл (например, пакет bank sdk для FusionPay), вы также можете установить или развернуть его на складе и поделиться им с другими проектами.

Склады делятся на локальные склады и удаленные склады. К удаленным складам относятся: частные серверы и центральные склады.

Когда зависимость объявлена, Maven ищет порядок сборки:

местный склад
репозиторий в профиле настроек maven;
репозиторий, указанный в профиле в pom.xml;
Репозитории в pom.xml (найти в порядке определения);
зеркало настроек maven;
центральный склад;

Жизненный цикл и плагины

Жизненный цикл Maven предназначен для абстрагирования и унификации всех процессов сборки, включая почти все этапы сборки, такие как очистка проекта, инициализация, компиляция, тестирование, упаковка, интеграционное тестирование, проверка, развертывание и создание сайта.

Жизненный цикл Maven абстрактен и сам по себе не выполняет никакой реальной работы. Фактические задачи передаютсяплагинЧто нужно сделать. Это означает, что Maven определяет только общую структуру алгоритма в родительском классе, а подкласс управляет фактическим поведением, переопределяя метод родительского класса (в режиме разработкиМетод шаблона Метод шаблона). Псевдокод выглядит следующим образом:

public abstract class AbstractBuilder {
    public void build() {
        init();
        compile();
        test();
        package();
        integrationTest();
        deploy();
    }
    
    protected abstract void init();
    protected abstract void compile();
    protected abstract void test();
    protected abstract void package();
    protected abstract void integrationTest();
    protected abstract void deploy();
}

Три набора жизненных циклов

Жизненный цикл Maven не является целым, у Maven естьТри независимых жизненных цикла, то есть чистый, по умолчанию и сайт соответственно.

Цель чистого жизненного цикла — очистить проект;
Целью жизненного цикла по умолчанию является сборка проекта;
Цель жизненного цикла сайта — создание сайта проекта;

Единый порядок выполнения жизненного цикла

Каждый жизненный цикл состоит из фаз, которые упорядочены иБолее поздние стадии зависят от более ранних стадий. Возьмем, к примеру, жизненный цикл очистки, он состоит из фаз предварительной очистки, очистки и последующей очистки. При вызове предварительной очистки выполняется только фаза предварительной очистки; при вызове очистки фазы предварительной очистки и очистки выполняются последовательно и так далее.

Отношения между различными жизненными циклами

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

Примечание. Таким образом, общие команды упаковкиclean package xxxxx, сначала очистить, а затем упаковать, потому что очистка и упаковка находятся в двух разных жизненных циклах.

Подробное объяснение каждого этапа жизненного цикла

clean

стадия жизненного цикла	описывать
pre-clean	Выполните некоторые работы, которые необходимо выполнить перед чисткой.
clean	Очистите файлы, созданные последней сборкой.
post-clean	Выполните некоторую работу, которую необходимо выполнить после очистки.

default

Есть 23 этапа, здесь представлены только ключевые этапы, как показано в следующей таблице:

стадия жизненного цикла	описывать
validate	Убедитесь, что конфигурация проекта верна и доступна вся необходимая информация для завершения процесса сборки.
initialize	Инициализируйте состояние сборки, например задайте свойства.
generate-sources
process-sources	Обработайте файл ресурсов проекта, обработайте основной файл ресурсов проекта. Вообще говоря, содержимое каталога src/main/resources копируется в основной каталог пути к классам выходных данных проекта после подстановки переменных и других действий.
generate-resources
process-resources
compile	Скомпилируйте основной исходный код проекта. Вообще говоря, файлы Java в каталоге src/main/java компилируются в основной каталог пути к классам выходных данных проекта.
process-classes	Обрабатывает скомпилированные файлы, такие как улучшения и оптимизации байт-кода класса Java.
generate-test-sources
process-test-sources	Обработка тестовых файлов ресурсов проекта. Вообще говоря, содержимое каталога src/test/resources копируется в каталог test classpath выходных данных проекта после подстановки переменных и других действий.
test-compile	Скомпилируйте тестовый код проекта. Вообще говоря, файлы Java в каталоге src/test/java компилируются в каталог test classpath выходных данных проекта.
process-test-classes
test	Запустите тесты, используя соответствующую среду модульного тестирования, такую как JUnit.
prepare-package	Сделайте все необходимое для подготовки к упаковке, прежде чем на самом деле упаковать.
package	Возьмите скомпилированный код и упакуйте его в пригодный для выпуска формат, такой как файл JAR, WAR или EAR.
pre-integration-test	Перед выполнением интеграционных тестов выполните необходимые действия. Например, установите необходимые переменные среды.
integration-test	Обработайте и разверните необходимые инженерные пакеты в среде, где можно запускать интеграционные тесты.
post-integration-test	Выполните необходимые действия после выполнения интеграционных тестов. Например, очистить окружающую среду.
verify	Запустите операции проверки, чтобы убедиться, что инженерные пакеты действительны и соответствуют требованиям качества.
install	Установите пакет проекта в локальный репозиторий, который можно использовать как зависимость от других локальных проектов.
deploy	Скопируйте окончательный пакет проекта в удаленный репозиторий, чтобы поделиться с другими разработчиками и проектами.

site

стадия жизненного цикла	описывать
pre-site	Выполните некоторую работу, которую необходимо выполнить перед созданием сайта проекта.
site	Создание документации сайта проекта.
post-site	Выполните некоторую работу, которую необходимо выполнить после создания сайта проекта.
site-deploy	Опубликуйте созданный сайт проекта на сервере.

плагин

Три определения жизненного цикла Maven не выполняют никакой реальной работы на каждом этапе, а фактическая работа выполняется подключаемыми модулями.Каждый этап жизненного цикла достигается целями плагина.. Объявите следующее в файле pom (плагин исходного файла пакета):

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>2.1.1</version>
            <executions>
                <execution>
                    <id>attach-sources</id>
                    <phase>verify</phase>
                    <goals>
                        <goal>jar-no-fork</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Цель плагина

Плагин может иметь несколько функций, и каждая функция является целью. Например, maven-dependency-plugin имеет более десяти целей, и каждая цель соответствует функции. Целями плагина являются зависимость: анализ, зависимость: дерево и зависимость: список. Общий метод написания: префикс плагина стоит перед двоеточием, а цель плагина — после двоеточия. Например, компилятор: скомпилировать.

插件目标

привязка плагина

插件绑定

встроенная привязка

Для быстрой сборки в Maven есть набор встроенных привязок плагинов. Привязки плагинов трех жизненных циклов таковы (собственно привязка каждой стадии жизненного цикла и цели плагина). Среди них метод построения жизненного цикла по умолчанию связан с его типом упаковки, а тип упаковки указан в упаковке в POM. Как правило, существует два типа: jar и war. Ниже приведен подключаемый модуль привязки по умолчанию и диаграмма жизненного цикла:

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

Пользовательская привязка позволяет нам контролировать сочетание целей плагина и жизненного цикла.В качестве примера возьмем исходный файл jar, который генерирует основной код проекта. Используемый плагин и его цель: maven-source-plugin:jar-no-fork. Привяжите его к проверке фазы жизненного цикла по умолчанию (любая фаза из трех жизненных циклов может быть указана произвольно).

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>2.1.1</version>
            <executions>
                <execution>
                    <id>attach-sources</id> 
                    <phase>verify</phase> <!-- 指定作用在生命周期的哪个阶段 -->
                    <goals>
                        <goal>jar-no-fork</goal> <!-- 指定执行绑定插件的哪些目标 -->
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Конфигурация плагина

Настройка с помощью командной строки

Добавьте параметр -D в команду maven вместе с формой ключ параметра = значение параметра, чтобы настроить целевые параметры плагина. Например, плагин maven-surefire-plugin предоставляет параметр maven.test.skip, когда значение равно true, он пропускает выполнение теста:

 -- 对比 mvn install
mvn install –Dmaven.test.skip=true

Использовать глобальную конфигурацию pom

При объявлении плагина сделайте глобальную конфигурацию плагина, и все последующие пользователи плагина должны следовать этой конфигурации. Например, укажите maven-compile-plugin для компиляции исходных файлов версии 1.7:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <configuration>
       <fork>true</fork>
       <source>1.7</source>
       <target>1.7</target>
   </configuration>
</plugin>

Получить информацию о плагине

Официальный сайт

maven.apache.org/plugins/Ind…
maven.apache.org/plugins-arc…

получить командную строку

Используйте плагин maven-help-plugin

mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin

mvn help:describe -Dplugin=compiler

mvn help:describe -Dplugin=compiler -Dgoal=compile

mvn help:describe -Dplugin=compiler -Ddetail

Используйте встроенную справку плагина

mvn compiler:help -Ddetail=true -Dgoal=compile

префикс плагина

Если плагин называется ${префикс}-maven-plugin или maven-$ В формате {prefix}-plugin его можно вызывать напрямую с префиксом mvn:goal.

Как посмотреть префикс плагинов: ${MAVEN_HOME}\org\apache\maven\plugins\maven-metadata-central.xml

Агрегация и наследование

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

<modules>
    <module>模块一</module>
    <module>模块二</module>
    <module>模块三</module>
</modules>

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

<parent>  
    <groupId>com.xxxx.maven</groupId>
    <artifactId>parent-project</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../ParentProject/pom.xml</relativePath>  
</parent>

Наследоваться могут следующие элементы:

groupId, идентификатор группы проекта;
версия, версия проекта;
описание, информация об описании предмета;
организация, организационная информация проекта;
inceptionYear, год основания проекта;
разработчики, информация о разработчиках проектов;
вкладчики, информация вкладчика проекта;
DistributionManagement, информация о развертывании проекта;
issueManagement, информация о системе отслеживания дефектов проекта;
ciManagement, система непрерывной интеграции информации о проекте;
scm, информация о системе контроля версий проекта;
mailingLists, информация о списке рассылки проекта;
свойства, пользовательские свойства Maven;
зависимости, конфигурация зависимостей проекта;
dependencyManagement, конфигурация управления зависимостями проекта;
репозитории, конфигурация репозитория проекта;
сборка, включая конфигурацию каталога исходного кода проекта, конфигурацию выходного каталога, конфигурацию подключаемых модулей, конфигурацию управления подключаемыми модулями и т. д.;
отчеты, включая конфигурацию выходного каталога отчета проекта и конфигурацию подключаемого модуля отчета.

Обратите внимание на следующие элементы, они не наследуются.

artifactId
name
prerequisites

Связь между агрегацией и наследованием:

Способ игры должен быть пом
В реальном проекте pom является одновременно совокупным pom и родительским pom.

Примечание:Зависимости, введенные зависимостями в родительском pom, также будут унаследованы дочерним pom, поэтому не ставьте слишком много фактических зависимостей на родительский pom, родительский pom используется только для управления, используйте тег dependencyManagement. (Здесь члены команды ступили на яму)

Создавайте гибко

Используйте свойства, функцию фильтра ресурсов плагина ресурсов (фильтр) и функцию профиля Maven для достижения гибкого переключения сред.

Атрибуты

maven.apache.org/shatter.HTML#PR…

С помощью элемента свойств пользователи могут настроить одно или несколько свойств Maven, а затем использовать их в другом месте pom.${属性名}Способ обращения к собственности, наибольшее значение этого способа заключается в устранении дублирования.

1. Встроенные свойства

${basedir}Представляет корневой каталог проекта, т. е. каталог, содержащий файл pom.xml.
${version}Эквивалентно${project.version}или${pom.version}Указывает версию проекта

2. Свойства ПОМ

Все элементы в pom можно использовать сproject.Например${project.artifactId}соответствует< project><artifactId>значение элемента. Общие свойства POM включают в себя:

${project.build.sourceDirectory}: основной каталог исходного кода проекта, по умолчанию — src/main/java/.
${project.build.testSourceDirectory}: тестовый исходный каталог проекта, по умолчанию /src/test/java/.
${project.build.directory}: выходной каталог сборки проекта, по умолчанию — target/.
${project.build.outputDirectory}: основной выходной каталог компиляции кода проекта, по умолчанию — target/classes/.
${project.build.testOutputDirectory}: выходной каталог компиляции тестового кода проекта, по умолчанию — target/testclasses/.
${project.groupId}: groupId проекта.
${project.artifactId}: идентификатор артефакта проекта.
${project.version}: версия проекта, эквивалентная${version} ${project.build.finalName}: имя выходного файла упаковки проекта, по умолчанию${project.artifactId}${project.version}

3. Пользовательские свойства

в пом<properties>пользовательские свойства Maven под элементом

<properties>
    <swagger.version>2.2.2</swagger.version>
</properties>
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>${swagger.version}</version>
</dependency>

4. Свойство настроек

Все настройки в используемом settings.xml доступны черезsettings.Ссылки на префикс аналогичны свойствам POM. как${settings.localRepository}Адрес, указывающий на локальный репозиторий пользователя.

5. Свойства системы Java

На все свойства системы Java можно ссылаться, используя свойства Maven, например.${user.home}указывает на каталог пользователя. через командную строкуmvn help:systemПросмотреть все свойства системы Java

6. Свойства переменных среды

Все переменные окружения могут использоваться дляenv.Ссылка на свойства Maven в начале. Например${env.JAVA_HOME}Относится к значению переменной среды JAVA_HOME. Вы также можете использовать командную строкуmvn help:systemПросмотрите все переменные среды.

7. Свойства родительского проекта

Переменные в pom родительского проекта имеют префикс${project.parent}Цитировать. На версию родительского проекта также можно ссылаться следующим образом:${parent.version}

Примечание. Как читать внешние файлы свойств?
Свойства Плагин Maven,GitHub.com/Capricorn OhhaUS/Лжец…

fileter

Свойства MavenfilterЭта функция может помочь вам автоматически заменить файл конфигурации на${}Обернутые переменные. Чтобы облегчить создание разных сред, мы обычно настраиваем разные конфигурации в pom в виде свойств. По умолчанию свойства Maven разрешаются только в POM. Фильтрация ресурсов относится к разрешению свойств Maven в файле ресурсов (src/main/resources,src/test/resources) также можно разобрать. Включите фильтрацию ресурсов:

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

Profile

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

pom.xml: Заявленный здесь профиль действителен только для текущего проекта.
Пользовательские настройки.xml: профиль в .m2/settings.xml действителен для проекта Maven этого пользователя.
Global settings.xml: conf/settings.xml, действительный для всех проектов Maven на этом компьютере.

Пример:

<project>
    ...
    <profiles>
      <profile>
        <id>dev</id>
        <properties>
            <active.profile>dev</active.profile>
            <key1>value1</key1>
            <key2>value2</key2>
        </properties>

        <!-- 默认激活配置 -->
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <!-- 在该 profile 下才会引入的依赖 -->
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>3.2.4.RELEASE</version>
            </dependency>
        <dependencies>
        <!-- 在该 profile 下才会加载的变量文件 -->
        <build>
            <filters>
                <filter>../profile/test-pre.properties</filter>
            </filters>
        </build>
            
      </profile>
    </profiles>
    ...
</project>

Теги, которые могут действовать в профиле

> <repositories>  
> <pluginRepositories>  
> <dependencies>  
> <plugins>  
> <properties> (not actually available in the main POM, but used behind the scenes)  
> <modules>  
> <reporting>  
> <dependencyManagement>  
> <distributionManagement>  
> a subset of the <build> element, which consists of:  
    > <defaultGoal>  
    > <resources>  
    > <testResources>  
    > <finalName>

Расширенные возможности

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

当使用 SNAPSHOT（快照版本）管理构件版本时，每次都会去远程仓库上最新的依赖。 Описание сценария применения:

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

Добавьте «-SNAPSHOT» после версии для автоматического развертывания в каталоге, соответствующем SNAPSHOT на удаленном складе.

Адаптируйте реактор, объедините комплектацию проекта и укажите комплектацию отдельных модулей

Описание сценария применения настраиваемого реактора: Совокупный проект содержит три основных приложения (таких как служба шлюза, поставщик услуг, проект помощника), структура примерно следующая:

-- 工程主目录
------ gateway 项目（可运行）
------ provider 项目（可运行）
------ assist 项目（可运行）
------ api 项目（被依赖）
------ common 项目（被依赖）
------ pom.xml

при выполнении в домашнем каталогеmvn packageПосле этого будут запакованы проекты шлюза, провайдера и помощника.В это время, если вам нужно набрать три проекта отдельно, вам нужно использовать реактор клиппинга. Если вы хотите упаковать проект провайдера отдельно, вы можете использовать следующую команду:

mvn package -pl provider -am

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

mvn package -pl gateway,assist -am

Детали реактораmvn -h:

-am --also-make также создает зависимости перечисленных модулей;
-amd -also-make-depends также собирает модули, которые зависят от перечисленных модулей;
-pl --projects Собрать указанные модули, разделенные запятыми;
-rf -resume-from Возобновить работу реактора из указанного модуля.

Плагин утилиты

Используйте плагин версий для пакетного изменения номера версии родительского pom.

-- https://blog.csdn.net/GGBomb2/article/details/78316068
-- 在顶级 pom 目录中设置版本号。
- 注：在 windows 下的 powershell 中 1.1.3-RELEASE 得加双引号
- 注：CMD 不用加
mvn versions:set -DnewVersion=1.1.3-RELEASE
-- 设置不正确时可以撤销新版本号的设置
mvn versions:revert
-- 确认新版本号无误后提交新版本号的设置
mvn versions:commit

Используйте плагин зависимостей для анализа зависимостей в вашем проекте.

mvn dependency:analyze

# 只想看依赖树中包含 groupId 为 javax.serlet 的枝干
mvn dependency:tree -Dincludes=javax.servlet
# 不想看依赖树中包含 groupId 为 javax.serlet 的枝干
mvn dependency:tree -Dexcludes=javax.servlet

Шаблон параметра определяется следующим образом:
[groupId]:[artifactId]:[type]:[version]

Каждая часть (часть, разделенная двоеточием) поддерживается*Подстановочный знак, если вы хотите указать несколько форматов, вы можете использовать,разделить, например:

mvn dependency:tree -Dincludes=javax.servlet,org.apache.*

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

<properties>
    <maven.deploy.skip>true</maven.deploy.skip>
</properties>

Используйте плагин тени для слияния файлов конфигурации и т. д.

no.OSCHINA.net/U/2377110/no…

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