предисловие
сказал в прошлый разВот как я использую Git на работе, Это уже история месячной давности, время, ах, вот так потихоньку проходит.
Давай поговорим на этот разmavenЭта штука, та же фраза, maven для меня просто инструмент, достаточно одних рутинных операций, и я изучу его углубленно, если будет время и интерес. Далее я запишу, что мне нужно, когда я использую maven注意и理解Что касается этих основных концепций и вопросов настройки среды, я думаю, все понимают.
склад
Репозиторий maven можно разделить на本地仓库и远程仓库.
Если компания построила собственный приватный сервер maven, его также можно разделить на本地仓库,私服仓库(内网),中央仓库(外网).
Частный сервер относится к складу maven, созданному внутренней сетью компании, который может использоваться внутренним персоналом компании.
Процесс поиска зависимых пакетов jar в pom.xml:
-
本地仓库找, найти и использовать напрямую, без необходимости подключения к Интернету. - локально не нашел,
私服仓库找, найдите его и загрузите локально для непосредственного использования в следующий раз. - Я не могу найти его на приватном сервере, я пойду напрямую
中央仓库找, а затем загрузите его на частный сервер или локально для непосредственного использования в следующий раз.
Если частного сервера нет, если вы не можете найти его на локальном складе, вы можете напрямую перейти на центральный склад, чтобы найти его.
процесс сборки
Каждая ссылка процесса сборки maven, представляющая определенный этап работы maven
- очистка: преобразовать ранее скомпилированный
旧的class字节码文件删除, готовясь к следующей компиляции. - Компиляция: преобразование исходной программы Java
编译成class字节码. - тест: автоматический тест,
自动调用junit程序. - Отчет: Результат выполнения тестовой программы.
- Упаковка: динамическая веб-инженерия
打war包, Java-инженерия打jar包. - Установить: упакованные файлы
复制到仓库中指定位置. - выпуск:
拷贝最终的工程包到远程仓库, для использования другими разработчиками.
Когда maven действительно работает, порядок не обязательно сверху вниз. Несколько этапов являются важными этапами, а не все этапы maven. Конкретный этап выполнения и порядок выполнения зависят от его жизненного цикла.
В некоторых статьях будет рассказано о последнем этапе сборки: развертывание -> копирование военного пакета, сгенерированного динамическим веб-проектом, в указанный каталог контейнера сервлетов и запуск. Для этого необходимо что-то настроить в контейнере сервлета, таком как tomcat, а затем выполнить команды, связанные с maven, и пакет war будет автоматически развернут в контейнере. Однако сейчас я в основном разрабатываю в среде SpringBoot, и развертывание военного пакета не существует. Заинтересованы в повторном знакомстве.
жизненный цикл
три комплекта相互独立Жизненный цикл независимо друг от друга определяет构建环节的执行顺序.
- чистый жизненный цикл: сделайте что-нибудь перед сборкой
清理工作. - жизненный цикл по умолчанию:
常用且核心, включая компиляцию, тестирование, упаковку, установку, публикацию и т. д. - жизненный цикл сайта: генерировать отчеты по проектам, сайты. Опубликовать сайт. (мало им пользовался....)
Опираясь на процесс сборки и жизненный цикл, описанные выше,maven执行任何一个阶段的时候，它前面的所有阶段都会执行.
Например, когда мы выполняем mvn install, код будет скомпилирован, протестирован и упакован. Но он не будет очищаться (clean), потому что install и clean находятся в разных жизненных циклах, но мы можем использовать их вместе, например: mvn clean install
Встроенный в Idea интерфейс maven также иллюстрирует этот момент.Нажмите на определенную стадию жизненного цикла, и maven выполнит предыдущую стадию до этой стадии.Если не верите, можете попробовать.
команда maven
В дополнение к работе с maven через интерфейс idea мы также можем вводить команды вручную, иначе что вы делаете в системе Linux?
- чистый мвн чистый
- скомпилировать mvn скомпилировать
- тест мвн тест
- пакет mvn пакет
- установить mvn установить
- опубликовать развертывание mvn
Выполните команду сборки maven, которая должна находиться в каталоге, где находится pom.xml.
В соответствии с жизненным циклом maven, когда вы запускаете mvn install, compile, test, package, intall будут выполняться последовательно, и то же самое справедливо и для mvn deploy.
В реальной разработке я напрямую ввожу команды для компиляции, упаковки и установки, и наиболее часто используемые из них:
mvn clean install -Dmaven.test.skip=true -U
Плюс очистка заключается в том, чтобы сначала очистить файлы, 100%, чтобы гарантировать, что после установки будут установлены последние измененные файлы.
Если текущий проект не должен зависеть от какого-либо другого проекта, его не нужно устанавливать, просто выполните mvn clean package
Команда mvn поддерживает параметры
- -U : этот параметр заставляет Maven проверять все зависимости SNAPSHOT на наличие обновлений, чтобы убедиться, что интеграция основана на последнем состоянии.
- -Dmaven.test.skip=true : не выполнять тестовые случаи и не компилировать классы тестовых случаев.
- -DskipTests: не выполнять тестовые примеры, а компилировать классы тестовых случаев для создания соответствующих файлов классов для целевых/тестовых классов.
- -P : Мультисредовая упаковка (будет описана позже)
плагин
Помимо хранения jar-пакетов, в репозитории maven также есть плагины. Основная программа определяет только абстрактный жизненный цикл, а конкретная работа по-прежнему должна выполняться конкретным подключаемым модулем.
Как правило, для компиляции я использую плагин maven-compiler-plugin, и определенная версия jdk должна быть такой же, как версия jdk, которую вы разработали и использовали, иначе будут различные странные проблемы, такие как ошибки при последующей упаковке.
В узле сборки pom.xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
Область зависимости
Определяет область, в которой можно управлять пакетом jar.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.1.3</version>
<scope>compile</scope>
</dependency>
-
compile: Зависит от проекта для участия в компиляции, тестировании, развертывании и запуске.
-
test: участвовать только в тестировании, включая компиляцию и запуск тестового кода.
-
при условии: Вы можете участвовать в компиляции и тестировании, но упаковка не будет внедрять
таблица для подведения итогов
| compile | test | provided | |
|---|---|---|---|
| основная программа | ✓ | × | ✓ |
| тестовая программа | ✓ | ✓ | ✓ |
| Участвовать в развертывании | ✓ | × | × |
Вышеупомянутые 3 более распространены, а остальные 3 менее распространены.
- время выполнения: нет необходимости участвовать в компиляции, пост-тестировании и цикле выполнения, обычно используется для пакетов jar, управляемых базой данных.
- система: пакет jar берется из пути локального вторичного диска, а не из хранилища maven.Как правило, для указания конкретного пути добавляется узел systemPath.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.1.3</version>
<scope>system</scope>
<systemPath>../xx/xx.jar</systemPath>
</dependency>
- импорт: импортировать что-то из другого пакета jar, поддерживается только для определения в
(примеры будут позже)
Примечание: некомпилируемые зависимости не могут быть транзитивными!
Способ упаковки
узел упаковки
<groupId>com.goku</groupId>
<artifactId>goku-manage</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
- pom: упакованы файлы зависимостей, которые можно использовать как maven-зависимости других проектов.Подпроекты наследуют родительский проект, а подпроекты могут напрямую использовать конфигурацию родительского проекта.Как правило, они используются в проектах агрегации для контроля версий пакетов jar .
- jar: общие проекты упакованы.Общие классы должны быть указаны во время разработки, и они упакованы в пакеты jar для удобства хранения и управления. SpringBoot имеет встроенный tomcat, который можно запускать непосредственно как банку.
- war: веб-проект упакован и развернут на сервере как военный пакет.
Агрегация и наследование
В проекте агрегации несколько pom.xml.
Родительский проект объединяет подпроекты через модули.Когда проект выполняет команду maven, два подпроекта также будут выполнены.
<modules>
<module>goku-user</module>
<module>goku-order</module>
</modules>
Дочерний проект наследует родительский проект через родительский тег и может напрямую ссылаться на элементы конфигурации родительского проекта.
<parent>
<groupId>com.goku</groupId>
<artifactId>goku-manage</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
Что касается преимуществ модуля агрегации, то их много, и есть два, которые действительно заставляют меня чувствовать себя
- Пакет зависимостей разумно разделен, структура ответственности понятна, и нет огромного pom.xml.
- После изменения внутреннего кода компилируется только текущий проект, что экономит время. Особенно подходит для распределенных проектов.
Единый номер версии
В проекте агрегации номер версии можно настроить и управлять им единообразно. Для разных проектов одной компании все зависимости должны иметь одинаковую версию.
Некоторые компании создают отдельный проект только для того, чтобы унифицировать номер версии, упаковать его в форму pom и наследовать для каждого проекта внутри компании.
Узел свойств в файле pom родительского проекта верхнего уровня
<properties>
<java.version>1.8</java.version>
<plugin.jdk.version>1.8</plugin.jdk.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<spring-boot.version>2.1.3.RELEASE</spring-boot.version>
<fasterjson.version>1.2.12</fasterjson.version>
</properties>
Версия зависимости ссылается на сконфигурированный номер версии.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>${spring-boot.version}</version>
</dependency>
dependencyManagement统一管理版本
请注意<scope>import</scope>
<dependencyManagement>
<dependencies>
<dependency>
<!-- Import dependency management from Spring Boot -->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.0.0.RELEASE</version>
<type>pom</type>
<!--导入spring-boot-dependencies里的配置，一定程度上解决了单继承问题。-->
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>${fasterjson.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
инструкция:
- dependencyManagement только объявляет зависимости и не вводит зависимости.
- Подмодуль не будет наследовать все предопределенные зависимости в dependencyManagement родительского модуля, если вы хотите его использовать, вам нужно ввести необходимые зависимости, но вам не нужно добавлять узел версии.
- Сказано, что прямое использование предопределенных зависимостей в родительском модуле категорически запрещено, и это должно вводиться по требованию.
Многоцелевая упаковка
При упаковке проекта различаются разные среды, фактически для разных сред генерируются разные файлы конфигурации.
Как правило, различают локальную, разработку/тестирование и онлайн.
сборка и профили в pom.xml (следующая конфигурация предназначена только для файла yml SpringBoot)
<build>
<!-- 打包后文件名称：项目名-环境-版本 -->
<finalName>${project.artifactId}</finalName>
<resources>
<resource>
<directory>src/main/resources</directory>
<!-- 开启过滤替换功能-->
<filtering>true</filtering>
<includes>
<!-- 项目打包完成的包中只包含当前环境文件 -->
<include>application.yml</include>
<include>application-${profileActive}.yml</include>
<include>**/*.xml</include>
<include>**/*.properties</include>
</includes>
</resource>
</resources>
</build>
<!-- 多环境配置方案 -->
<profiles>
<profile>
<id>local</id>
<properties>
<profileActive>local</profileActive>
</properties>
<activation>
<!-- 默认情况下使用本地开发配置 如 打包时不包含 -p 参数-->
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<!-- 打包命令package -P test -->
<profile>
<id>test</id>
<properties>
<profileActive>test</profileActive>
</properties>
</profile>
<!-- 打包命令package -P prod -->
<profile>
<id>prod</id>
<properties>
<profileActive>prod</profileActive>
</properties>
</profile>
</profiles>
Команда maven принимает параметр -P, например: mvn clean install -P test
После упаковки проекта остаются только application.yml и ymlapplication-test.yml.
@profileActive@ в application.yml также будет заменен на test
Окончательный упакованный файл
setting.xml
localRepository
Укажите адрес локального хранилища и поместите его в путь по умолчанию ${user.home}/.m2/repository без настройки
<localRepository>D:\develop\maven\Repmaven</localRepository>
server
Компания построила частный сервер maven, а загрузка и загрузка требуют аутентификации и настройки.
NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are used together.
Настраиваемый пароль учетной записи или форма закрытого ключа, поддержка нескольких серверов
<servers>
<server>
<!--id需要与repository或mirror中的id相对应-->
<id>server01</id>
<username>admin</username>
<password>SwaDmin159</password>
</server>
<server>
<id>server02</id>
<privateKey>/xxx/.ssh/id_dsa</privateKey>
<passphrase>some_passphrase</passphrase>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration></configuration>
</server>
</servers>
mirror
Зеркало склада, агент центрального склада, если зеркало настроено, оно будет напрямую обращаться к зеркалу для загрузки зависимостей. Это эквивалентно перехватчику, который перехватывает запрос maven к центральному хранилищу по умолчанию и перенаправляет адрес удаленного хранилища в запросе на адрес, настроенный в зеркале.
<mirrors>
<mirror>
<id>nexus-aliyun</id>
<mirrorOf>central</mirrorOf>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
</mirrors>
profile and activeProfiles
Все проекты используют репозиторий частного сервера, который можно настроить в settings.xml, настроить репозитории в узле профиля и, наконец, активировать профиль.
Конечно, на частном сервере имеется более одного репозитория, и можно настроить несколько репозиториев.
<profile>
<repositories>
<repository>
<!-- id需要与私服里仓库的id对应 -->
<id>public</id>
<name>public</name>
<url>http://xxx.com/nexus/content/groups/public/</url>
<layout>default</layout>
</repository>
</repositories>
</profile>
<activeProfiles>
<activeProfile>public</activeProfile>
</activeProfiles>
Если вы хотите настроить таргетинг только на определенный проект, вы можете настроить частный сервер в файле pom.xml текущего проекта и настроить его в узле репозиториев.
<repositories>
<repository>
<!-- id需要与私服里仓库的id对应 -->
<id>public</id>
<name>public</name>
<url>http://xxx.com/nexus/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
distributionManagement
Иногда модули, которые мы разработали сами, должны использоваться разработчиками в других отделах, поэтому нам нужно публиковать их на частных серверах.
Перед выполнением mvn deploy вам необходимо настроить дистрибутивManagement.
Версия моментального снимка и версия выпуска хранятся по разным адресам склада.
<distributionManagement>
<repository>
<id>release</id>
<name>Project Release</name>
<url>http://xxx.com/nexus/content/groups/release/</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Project SNAPSHOTS</name>
<url>http://xxx.com/nexus/content/groups/snapshot/</url>
</snapshotRepository>
</distributionManagement>
Снимок против выпуска
Maven будет судить, является ли это версией моментального снимка или официальной версией, в зависимости от того, имеет ли номер версии (узел версии) пакета jar -SNAPSHOT. Никакой SNAPSHOT не считается версией моментального снимка.
Версия снимка: 1.0.0-SNAPSHOT
Версия выпуска: 1.5.3.RELEASE
Если это версия моментального снимка, она будет автоматически выпущена в библиотеку версии моментального снимка во время развертывания mvn, перезаписывая старую версию моментального снимка, и при последующем использовании модуля версии моментального снимка, когда номер версии не изменяется, при прямой компиляции и упаковке, maven автоматически загрузит с удаленного сервера. Загрузите последнюю версию моментального снимка на сервере.
Если это официальная версия релиза, она будет автоматически выпущена в библиотеку официальной версии во время развертывания mvn, а официальная версия модуля будет использоваться позже.Без изменения номера версии, если модуль этой версии уже существует локально, когда компилируя и упаковывая, он не будет проявлять инициативу.Перейдите на удаленный сервер для загрузки.
Это также легко понять: снэпшоты обычно определяются как нестабильные версии и должны обновляться в режиме реального времени.
Суммировать
Наконец
Если вы считаете, что эта статья была для вас полезной, пожалуйста, поставьте небольшой лайк, это будет для меня самой большой поддержкой!
WeChat поиск悟空JavaИли отсканируйте QR-код, чтобы подписаться на официальный аккаунт Wukong, учитесь и развивайтесь вместе!