Maven详解 - 技术栈

安装配置maven

1. Maven软件的下载

使用 Maven 管理工具，我们首先要到官网去下载它的安装软件。

Maven -- Download Apache Maven

2. Maven软件的安装

Maven 下载后，将 Maven 解压到一个没有中文没有空格的路径下，比如:H:\software\maven 下面。解压后目录结构如下：

bin:存放了 maven 的命令
boot:存放了一些 maven 本身的引导程序，如类加载器等
conf:存放了 maven 的一些配置文件，如 setting.xml 文件
lib:存放了 maven 本身运行所需的一些 jar 包

3.Maven环境变量配置

配置 MAVEN_HOME ，变量值就是你的 maven 安装的路径（bin 目录之前一级目录）

将MAVEN_HOME 添加到Path系统变量

4. Maven 软件版本测试

win+R 打开dos窗口，通过 mvn -v命令检查 maven 是否安装成功，看到 maven 的版本为 3.6.3 及 java 版本为 jdk-11 即为安装成功。打开命令行，输入 mvn --v命令，如下图：

5、Maven 仓库

Maven中的仓库是用来存放maven构建的项目和各种依赖的(Jar包)。

Maven的仓库分类

本地仓库: 位于自己计算机中的仓库, 用来存储从远程仓库或中央仓库下载的插件和 jar 包，
远程仓库: 需要联网才可以使用的仓库，阿里提供了一个免费的maven 远程仓库。
中央仓库: 在 maven 软件中内置一个远程仓库地址 http://repo1.maven.org/maven2 ，它是中央仓库，服务于整个互联网，它是由 Maven 团队自己维护，里面存储了非常全的 jar 包，它包含了世界上大部分流行的开源项目构件

6.Maven 本地仓库的配置

maven仓库默认是在 C盘 .m2 目录下,我们不要将仓库放在C盘,所以这里要重新配置一下.

在maven安装目录中,进入 conf文件夹, 可以看到一个 settings.xml 文件中, 我们在这个文件中, 进行本地仓库的配置

打开 settings.xml文件，进行如下配置如下：

配置阿里云远程仓库

Maven默认的远程仓库是在国外, 所以下载jar包时速度会非常慢, 这里推荐大家使用阿里云仓库

打开 settings.xml,找到标签 , 下面的内容复制到对应位置即可


<mirror>

<id>alimaven</id>

<name>aliyun maven</name>

<url>

http://maven.aliyun.com/nexus/content/groups/public/

</url>

<mirrorOf>central</mirrorOf>

</mirror>

至此，maven安装配置完毕，接下来可以去IDEA中创建Maven项目啦。

maven基本介绍

Maven 是 Apache 软件基金会组织维护的一款专门为 Java 项目提供构建和依赖管理支持的工具。

每一个 Maven 工程都有一个 pom.xml 文件，位于根目录中，包含项目构建生命周期的详细信息。通过 pom.xml 文件，我们可以定义项目的坐标、项目依赖、项目信息、插件信息等等配置。

对于开发者来说，Maven 的主要作用主要有 3 个：

项目构建：提供标准的、跨平台的自动化项目构建方式。
依赖管理：方便快捷的管理项目依赖的资源（jar 包），避免资源间的版本冲突问题。
统一开发结构：提供标准的、统一的项目结构。

项目中依赖的第三方库以及插件可统称为构件。每一个构件都可以使用 Maven 坐标唯一标识，坐标元素包括：

groupId(必须): 定义了当前 Maven 项目隶属的组织或公司。groupId 一般分为多段，通常情况下，第一段为域，第二段为公司名称。域又分为 org、com、cn 等，其中 org 为非营利组织，com 为商业组织，cn 表示中国。以 apache 开源社区的 tomcat 项目为例，这个项目的 groupId 是 org.apache，它的域是 org（因为 tomcat 是非营利项目），公司名称是 apache，artifactId 是 tomcat。
artifactId(必须)：定义了当前 Maven 项目的名称，项目的唯一的标识符，对应项目根目录的名称。
version(必须)：定义了 Maven 项目当前所处版本。
packaging（可选）：定义了 Maven 项目的打包方式（比如 jar，war...），默认使用 jar。
classifier(可选)：常用于区分从同一 POM 构建的具有不同内容的构件，可以是任意的字符串，附加在版本号之后。

只要你提供正确的坐标，就能从 Maven 仓库中找到相应的构件供我们使用。

如

<dependency>

<groupId>com.alibaba</groupId>

<artifactId>easyexcel</artifactId>

<version>3.1.1</version>

</dependency>

依赖配置

<project>

<dependencies>

<dependency>

<groupId></groupId>

<artifactId></artifactId>

<version></version>

<type>...</type>

<scope>...</scope>

<optional>...</optional>

<exclusions>

<exclusion>

<groupId>...</groupId>

<artifactId>...</artifactId>

</exclusion>

</exclusions>

</dependency>

</dependencies>

</project>

配置说明：

dependencies：一个 pom.xml 文件中只能存在一个这样的标签，是用来管理依赖的总标签。
dependency：包含在 dependencies 标签中，可以有多个，每一个表示项目的一个依赖。
groupId,artifactId,version(必要)：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven 根据坐标才能找到需要的依赖。我们在上面解释过这些元素的具体意思，这里就不重复提了。
type(可选)：依赖的类型，对应于项目坐标定义的 packaging。大部分情况下，该元素不必声明，其默认值是 jar。
scope(可选)：依赖的范围，默认值是 compile。
optional(可选)：标记依赖是否可选
exclusions(可选)：用来排除传递性依赖,例如 jar 包冲突

maven的父子工程依赖传递机制

1.通常我们在依赖升级的时候会遇到以下问题:

多个依赖关联升级
多个模块需要一起升级

2.我们正在维护一个Maven工程时，需要关注的一个点是如何优雅地管理依赖

在父模块中使用dependencyManagement，配置依赖

在子模块中使用dependencies，使用依赖
基于上述，我们需要在父子工程中配置统一的依赖管理

在父模块的pom.xml中，我们配置了基础的spring-boot依赖，也配置了日志输出需要的logback依赖，可以看出，我们遵循了以下的原则：

（1）在所有子模块的父模块中的pom中配置dependencyManagement，统一管理依赖版本。在子模块中直接配置依赖，不用再纠缠于具体的版本，避免潜在的依赖版本冲突。

（2）把groupId相同的依赖，配置在一起，比如groupId为org.springframework.boot，我们配置在了一起。

（3）把groupId相同，但是需要一组依赖共同提供功能的artifactId，配置在一起，同时将版本号抽取成变量，便于后续一组功能共同的版本升级。比如spring-boot依赖的版本抽取成了spring-boot.version。

<properties>
    ...
    <spring-boot.version>2.3.0.RELEASE</spring-boot.version>
    ...
    <logback.version>1.2.3.12-struct</logback.version>
    ...
    <h2.database.version>1.4.199</h2.database.version>
    ...
  </properties>

  <dependencyManagement>
    ...
    <dependencies>
      <!-- spring-boot -->
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>${spring-boot.version}</version>
      </dependency>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
        <version>${spring-boot.version}</version>
      </dependency>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <version>${spring-boot.version}</version>
        <scope>test</scope>
      </dependency>      
      ...
      <!-- log -->
      <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>${logback.version}</version>
      </dependency>
      <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-core</artifactId>
        <version>${logback.version}</version>
      </dependency>
      <!-- test db -->
      <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>${h2.database.version}</version>
        <scope>test</scope>
      </dependency>
      ...
    </dependencies>
  </dependencyManagement>

在子模块build-engine-api的pom.xml中，由于在父pom中配置了 dependencyManagement中依赖的spring-boot相关依赖的版本，因此在子模块的pom中，只需要在dependencies中直接声明依赖，确保了依赖版本的一致性。

 <parent>
    <groupId>com.alibaba.aone</groupId>
    <artifactId>build-engine</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../pom.xml</relativePath>
  </parent>

   ...

  <dependencies>
     <dependency>
       <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
     </dependency>
     ...
  </dependencies>

依赖的传递

A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？

再以上的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

B 依赖 C 时使用 compile 范围：可以传递
B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。

依赖的排除

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。

所以配置依赖的排除其实就是阻止某些 jar 包的传递。因为这样的 jar 包传递过来会和其他 jar 包冲突。

一般通过使用excludes标签配置依赖的排除：

<dependency>
	<groupId>net.javatv.maven</groupId>
	<artifactId>auth</artifactId>
	<version>1.0.0</version>
	<scope>compile</scope>
    
	<!-- 使用excludes标签配置依赖的排除	-->
	<exclusions>
		<!-- 在exclude标签中配置一个具体的排除 -->
		<exclusion>
			<!-- 指定要排除的依赖的坐标（不需要写version） -->
			<groupId>commons-logging</groupId>
			<artifactId>commons-logging</artifactId>
		</exclusion>
	</exclusions>
</dependency>

maven生命周期

Maven 的生命周期就是为了对所有的构建过程进行抽象和统一，包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。

Maven 定义了 3 个生命周期META-INF/plexus/components.xml：

default 生命周期
clean生命周期
site生命周期

这些生命周期是相互独立的，每个生命周期包含多个阶段(phase)。并且，这些阶段是有序的，也就是说，后面的阶段依赖于前面的阶段。当执行某个阶段的时候，会先执行它前面的阶段。

default 生命周期

default生命周期是在没有任何关联插件的情况下定义的，是 Maven 的主要生命周期，用于构建应用程序，共包含 23 个阶段。

<phases>
  <!-- 验证项目是否正确，并且所有必要的信息可用于完成构建过程 -->
  <phase>validate</phase>
  <!-- 建立初始化状态，例如设置属性 -->
  <phase>initialize</phase>
  <!-- 生成要包含在编译阶段的源代码 -->
  <phase>generate-sources</phase>
  <!-- 处理源代码 -->
  <phase>process-sources</phase>
  <!-- 生成要包含在包中的资源 -->
  <phase>generate-resources</phase>
  <!-- 将资源复制并处理到目标目录中，为打包阶段做好准备。 -->
  <phase>process-resources</phase>
  <!-- 编译项目的源代码  -->
  <phase>compile</phase>
  <!-- 对编译生成的文件进行后处理，例如对 Java 类进行字节码增强/优化 -->
  <phase>process-classes</phase>
  <!-- 生成要包含在编译阶段的任何测试源代码 -->
  <phase>generate-test-sources</phase>
  <!-- 处理测试源代码 -->
  <phase>process-test-sources</phase>
  <!-- 生成要包含在编译阶段的测试源代码 -->
  <phase>generate-test-resources</phase>
  <!-- 处理从测试代码文件编译生成的文件 -->
  <phase>process-test-resources</phase>
  <!-- 编译测试源代码 -->
  <phase>test-compile</phase>
  <!-- 处理从测试代码文件编译生成的文件 -->
  <phase>process-test-classes</phase>
  <!-- 使用合适的单元测试框架（Junit 就是其中之一）运行测试 -->
  <phase>test</phase>
  <!-- 在实际打包之前，执行任何的必要的操作为打包做准备 -->
  <phase>prepare-package</phase>
  <!-- 获取已编译的代码并将其打包成可分发的格式，例如 JAR、WAR 或 EAR 文件 -->
  <phase>package</phase>
  <!-- 在执行集成测试之前执行所需的操作。 例如，设置所需的环境 -->
  <phase>pre-integration-test</phase>
  <!-- 处理并在必要时部署软件包到集成测试可以运行的环境 -->
  <phase>integration-test</phase>
  <!-- 执行集成测试后执行所需的操作。 例如，清理环境  -->
  <phase>post-integration-test</phase>
  <!-- 运行任何检查以验证打的包是否有效并符合质量标准。 -->
  <phase>verify</phase>
  <!-- 	将包安装到本地仓库中，可以作为本地其他项目的依赖 -->
  <phase>install</phase>
  <!-- 将最终的项目包复制到远程仓库中与其他开发者和项目共享 -->
  <phase>deploy</phase>
</phases>

clean 生命周期

clean 生命周期的目的是清理项目，共包含 3 个阶段：

pre-clean
clean
post-clean
<phases> <phase>pre-clean</phase> <phase>clean</phase> <phase>post-clean</phase> </phases> <default-phases> <clean> org.apache.maven.plugins:maven-clean-plugin:2.5:clean </clean> </default-phases>

根据前面提到的阶段间依赖关系理论，当我们执行 mvn clean 的时候，会执行 clean 生命周期中的 pre-clean 和 clean 阶段。

site 生命周期

site 生命周期的目的是建立和发布项目站点，共包含 4 个阶段：

pre-site
site
post-site
site-deploy
<phases> <phase>pre-site</phase> <phase>site</phase> <phase>post-site</phase> <phase>site-deploy</phase> </phases> <default-phases> <site> org.apache.maven.plugins:maven-site-plugin:3.3:site </site> <site-deploy> org.apache.maven.plugins:maven-site-plugin:3.3:deploy </site-deploy> </default-phases>

Maven 能够基于 pom.xml 所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息。

maven的依赖范围

引入依赖存在一个范围，maven的依赖范围包括： compile，provide，runtime，test，system, import。原则上，只按照实际情况配置依赖的范围，在必要的阶段，只引入必要的依赖。

compile：表示编译范围，指 A 在编译时依赖 B，该范围为默认依赖范围。编译范围的依赖会用在编译，测试，运行，由于运行时需要，所以编译范围的依赖会被打包。
provided：provied 依赖只有当 jdk 或者一个容器已提供该依赖之后才使用。provide 依赖在编译和测试时需要，在运行时不需要。例如：servlet api被Tomcat容器提供了。
runtime：runtime 依赖在运行和测试系统时需要，但在编译时不需要。例如：jdbc 的驱动包。由于运行时需要，所以 runtime 范围的依赖会被打包。
test：test 范围依赖在编译和运行时都不需要，只在测试编译和测试运行时需要。例如：Junit。由于运行时不需要，所以 test 范围依赖不会被打包。
system：system 范围依赖与 provide 类似，但是必须显示的提供一个对于本地系统中 jar 文件的路径。一般不推荐使用。
import：只在<dependencyManagement>内定义的<dependency>中支持import这一scope。项目A和项目B的pom.xml文件中都定义了<dependencyManagement>，同时在B的<dependencyManagement>中定义<dependency>指向A，且scope为import：这就相当于将A中定义的所有<dependencies>全部复制粘贴到了项目B的pom.xml中。由于是"复制粘贴"，所以不是继承关系。另外，一个小tip，如果在B中要对A中定义的dependency覆盖，应该注意顺序，将对A的依赖写在下面。打包类型必须是 pom

90%的Java程序员应该都使用过org.projectlombok:lombok来简化我们的代码，其原理就是在编译过程中将注解转化为Java实现。因此该依赖的scope为provided，也就是编译时需要，但在构建出最终产物时又需要被排除。

  ...
  <dependencies>
     <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <scope>provided</scope>
    </dependency>
    ...
  </dependencies>
 ...

当你的代码需要使用JDBC连接一个MySQL数据库，通常我们会希望针对标准 JDBC 抽象进行编码，而不是直接错误的使用 MySQL driver实现。这个时候依赖的scope就需要设置为runtime。这意味着我们在编译时无法使用该依赖，该依赖会被包含在最终的产物中，在程序最终执行时可以在classpath下找到它。

 ...
  <dependencies>
     <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>
    ...
  </dependencies>
 ...

在子模块dao中，我们有对sql进行测试的场景，需要引入内存数据库h2。

因此，我们将h2的scope设置为test，这样我们在测试编译和执行时可以使用，同时避免其出现在最终的产物中。

  ...
  <dependencies>
     <dependency>
       <groupId>com.h2database</groupId>
       <artifactId>h2</artifactId>
       <scope>test</scope>
    </dependency>
    ...
  </dependencies>
 ...

maven的插件

Maven 本质上是一个插件执行框架，所有的执行过程，都是由一个一个插件独立完成的。像咱们日常使用到的 install、clean、deploy 等命令，其实底层都是一个一个的 Maven 插件。关于 Maven 的核心插件可以参考官方的这篇文档：https://maven.apache.org/plugins/index.htmlopen in new window 。

本地默认插件路径: ${user.home}/.m2/repository/org/apache/maven/plugins

除了 Maven 自带的插件之外，还有一些三方提供的插件比如单测覆盖率插件 jacoco-maven-plugin、帮助开发检测代码中不合规范的地方的插件 maven-checkstyle-plugin、分析代码质量的 sonar-maven-plugin。并且，我们还可以自定义插件来满足自己的需求。

<build>
  <plugins>
    <plugin>
      <groupId>org.jacoco</groupId>
      <artifactId>jacoco-maven-plugin</artifactId>
      <version>0.8.8</version>
      <executions>
        <execution>
          <goals>
            <goal>prepare-agent</goal>
          </goals>
        </execution>
        <execution>
          <id>generate-code-coverage-report</id>
          <phase>test</phase>
          <goals>
            <goal>report</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

你可以将 Maven 插件理解为一组任务的集合，用户可以通过命令行直接运行指定插件的任务，也可以将插件任务挂载到构建生命周期，随着生命周期运行。

Maven 插件被分为下面两种类型：

Build plugins：在构建时执行。
Reporting plugins：在网站生成过程中执行。

build指定JDK版本

maven默认所用的jdk版本并不是1.8

思路就是我们直接把 JDK 版本信息告诉负责编译操作的 maven-compiler-plugin 插件，让它在构建过程中，按照我们指定的信息工作。如下：

<!-- build 标签：意思是告诉 Maven，你的构建行为，我要开始定制了！ -->
<build>
    <!-- plugins 标签：Maven 你给我听好了，你给我构建的时候要用到这些插件！ -->
    <plugins>
        <!-- plugin 标签：这是我要指定的一个具体的插件 -->
        <plugin>
            <!-- 插件的坐标。此处引用的 maven-compiler-plugin 插件不是第三方的，是一个 Maven 自带的插件。 -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            
            <!-- configuration 标签：配置 maven-compiler-plugin 插件 -->
            <configuration>
                <!-- 具体配置信息会因为插件不同、需求不同而有所差异 -->
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>

SpringBoot 定制化打包

很显然 spring-boot-maven-plugin 并不是 Maven 自带的插件，而是 SpringBoot 提供的，用来改变 Maven 默认的构建行为。具体来说是改变打包的行为。默认情况下 Maven 调用 maven-jar-plugin 插件的 jar 目标，生成普通的 jar 包。普通 jar 包没法使用 java -jar xxx.jar 这样的命令来启动、运行，但是 SpringBoot 的设计理念就是每一个『微服务』导出为一个 jar 包，这个 jar 包可以使用 java -jar xxx.jar 这样的命令直接启动运行这样一来，打包的方式肯定要进行调整。所以 SpringBoot 提供了 spring-boot-maven-plugin 这个插件来定制打包行为。

<build>
	<plugins>
		<plugin>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-maven-plugin</artifactId>
			<version>2.5.5</version>
		</plugin>
	</plugins>
</build>

maven多环境支持

就MySQL 来说，不同环境下的访问参数肯定完全不同，可是代码只有一套。如果在 jdbc.properties 里面来回改，那就太麻烦了，而且很容易遗漏或写错，增加调试的难度和工作量。所以最好的办法就是把适用于各种不同环境的配置信息分别准备好，部署哪个环境就激活哪个配置。

从外部视角来看，profile 可以在下面两种配置文件中配置：

settings.xml：全局生效。其中我们最熟悉的就是配置 JDK 1.8。
pom.xml：当前 POM 生效

下面我们来看一个具体例子。假设有如下 profile 配置，在 JDK 版本为 1.6 时被激活：

<profiles>
	<profile>
    	<id>JDK1.6</id>
        <activation>
            <!-- 指定激活条件为：JDK 1.6 -->
        	<jdk>1.6</jdk>
        </activation>
        ......
    </profile>
</profiles>

这里需要指出的是：Maven 会自动检测当前环境安装的 JDK 版本，只要 JDK 版本是以 1.6 开头都算符合条件。

一般我们项目至少有三种运行环境：

开发环境：供不同开发工程师开发的各个模块之间互相调用、访问；内部使用
测试环境：供测试工程师对项目的各个模块进行功能测试；内部使用
生产环境：供最终用户访问------所以这是正式的运行环境，对外提供服务

因此我们可以利用 Maven 的 profile 来进行定义多个 profile，然后每个profile对应不同的激活条件和配置信息，从而达到不同环境使用不同配置信息的效果。

<build>
    <!-- profile对资源的操作 -->
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <!-- 先排除所有环境相关的配置文件 -->
            <excludes>
                <exclude>application*.yml</exclude>
            </excludes>
        </resource>
        <resource>
            <directory>src/main/resources</directory>
            <!-- 是否替换 @xx@ 表示的maven properties属性值 -->
            <!--通过开启 filtering，maven 会将文件中的 @xx@ 替换 profile 中定义的 xx 变量/属性-->
            <filtering>true</filtering>
            <includes>
                <include>application.yml</include>
                <include>application-${profileActive}.yml</include>
            </includes>
        </resource>
    </resources>
</build>


<!--多环境文件配置-->
<profiles>
    <!--开发环境-->
    <profile>
        <id>dev</id>
        <activation>
            <!--默认激活-->
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <profileActive>dev</profileActive>
        </properties>
    </profile>
    <!--测试环境-->
    <profile>
        <id>test</id>
        <properties>
            <profileActive>test</profileActive>
        </properties>
    </profile>
    <!--正式环境-->
    <profile>
        <id>prod</id>
        <properties>
            <profileActive>prod</profileActive>
        </properties>
    </profile>
</profiles>

在 idea 中可以看到，因此，当你需要打包哪一个环境的就勾选即可：

同时，SpringBoot 天然支持多环境配置，一般来说，application.yml存放公共的配置，application-dev.yml、application-test.yml、application.prod.yml分别存放三个环境的配置。如下：

application.yml 中配置spring.profiles.active=prod（或者dev、test）指定使用的配置文件

注：profileActive，就是上面我们自定义的标签。

然后当我们勾选哪一个环境，打包的配置文件就是那一个环境：