Maven 教程

1 Maven 简介

Maven 是一款基于 Java 平台的项目管理和整合工具，将项目的开发和管理过程抽象成一个项目对象模型（POM）。开发人员只需要进行简单的配置，Maven 就可以自动完成项目的编译、测试、打包、发布以及部署等工作。

Maven 使用 Java 语言编写，因此与 Java 一样具有跨平台性，无论是在 Windows、Linux 还是 Mac OS上，都可以使用相同的命令进行操作。它使用标准的目录结构和默认构建生命周期，使开发者能够自动化地完成项目的基础构建工作。

Maven 的主要功能包括构建项目、生成文档、创建报告、维护依赖、软件配置管理以及发布和部署。它抽象了完整的构建生命周期模型，使得项目的编译、生成文档、创建报告、发布、部署等任务能够无缝衔接，构建成一套完整的生命周期。

在 Maven 管理的项目中，根目录下会有一个 pom.xml 文件，该文件指示 Maven 如何工作。在 pom.xml 文件中，可以配置项目的基本信息以及项目构建信息，如项目坐标、项目依赖的 jar 包、插件和编译选项等。一旦在 pom.xml 文件中配置了所依赖的 jar 包，Maven 会自动从构建仓库中下载相应的构件。

此外，Maven 还提出了仓库的概念，使得我们可以将第三方和需要引用的项目都放置在 Maven 仓库中。这样，其他人或项目组如果需要使用，就可以直接通过 Maven 进行配置，从而降低了人员成本和沟通成本。

2 Maven 安装和配置

Maven 的安装和配置主要分为以下几个步骤：

下载 Maven

前往 Maven 的官方网站，下载最新的 Maven 压缩包。

安装 Maven

将下载的 Maven 压缩包解压到一个没有中文、空格或其他特殊字符的文件夹内。注意，解压路径中不能包含中文、空格或其他特殊字符，这可能会导致 Maven 无法正确运行。

配置环境变量

新建系统变量 MAVEN_HOME，并将其值设置为 Maven 解压后的目录路径。在系统变量 Path 中添加 %MAVEN_HOME%\bin，这样可以在任何位置通过命令行运行 Maven。

测试 Maven 安装

打开命令窗口（在 Windows 中可以通过按下 Win+R 键，然后输入 cmd 来打开），输入 mvn -v 命令。如果命令窗口能够正确显示 Maven 的版本信息和其他相关配置，那么说明 Maven 已经安装成功并且环境变量配置正确。

配置 Maven 本地仓库和镜像

配置本地仓库：Maven 从中央仓库下载的 jar 包存放的地方称之为本地仓库。你可以新建一个文件夹（如 maven-repository）作为本地仓库，并在 Maven 的 settings.xml 文件中配置该本地仓库的地址。

配置 Maven 镜像：由于从中央仓库下载数据速度可能较慢，可以配置镜像地址以加快下载速度。在 settings.xml 文件中，你可以添加或修改镜像配置，指定一个速度更快的镜像仓库地址。

完成以上步骤后，Maven 就已经成功安装并配置好了。你可以开始使用 Maven 来管理你的 Java 项目了。

需要注意的是，Maven 的使用是基于 JDK 的，因此在安装和配置 Maven 之前，你需要确保你的电脑上已经安装了合适版本的 JDK，并且配置好了 JDK 的环境变量。

3 基于 IDEA 创建 Maven 工程

3.1 GAV

Maven 的 GAV 规则是指在使用 Maven 进行项目构建和依赖管理时，对于项目坐标的规范定义。GAV 是 GroupId、ArtifactId 和 Version 三个元素的缩写，它们共同构成了 Maven 项目的唯一标识符。

以下是 Maven GAV 规则的详细说明：

GroupId（G）

代表项目的组织或公司。通常采用公司域名的倒写形式，例如 com.example。如果项目属于某个特定的业务线或子业务线，也可以在 GroupId 中反映出来。格式上，通常遵循 com.{公司/BU}.业务线.[子业务线] 的结构，最多可以有四级。例如 com.alibaba.taobao.tmall。

ArtifactId（A）

代表项目中的模块或产品线名称。它应该具有语义上的唯一性，不与其他项目或模块重复。格式上，通常采用产品线名-模块名的形式。例如 spring-webmvc。

Version（V）

表示项目的版本信息。对于 Maven 来说，版本号是区分不同版本的唯一标识。

版本号通常遵循一定的命名规则，例如主版本号.次版本号.修订号的形式（如 4.3.7.RELEASE）。修订号通常用于标识没有修改方法签名的功能加强或 bug 修复，以保持 API 的兼容性。

GAV 规则的作用在于确保 Maven 项目在仓库中的唯一性，使得 Maven 能够准确地定位和获取项目所需的依赖。通过 GAV，Maven 能够自动下载、管理项目的依赖关系，并在构建过程中进行必要的处理。

在使用 Maven 进行项目构建时，开发者需要在项目的 pom.xml 文件中指定正确的 GAV 信息，以便 Maven 能够正确地构建和管理项目。同时，开发者也可以通过 Maven 仓库搜索引擎来查找和获取所需的依赖项及其对应的 GAV 信息。

3.2 packaging

在 Maven 中，packaging 是一个重要的概念，它定义了项目的打包方式。Maven 支持多种打包方式，如 war、jar、pom。

jar 打包

当项目的 packaging 设置为 jar 时，Maven 会将其编译后的代码和相关资源文件打包成一个 jar 文件。这种打包方式适用于那些作为库文件被其他项目依赖的项目，或者那些作为可执行的命令行工具的项目。

默认情况下，如果 pom.xml 文件中没有显式指定 packaging 元素，Maven 会默认使用 jar 打包方式。

war 打包

当项目的 packaging 设置为 war 时，Maven 会将其编译后的代码、相关资源文件以及 Web 应用特有的内容（如 JSP 文件、静态资源等）打包成一个 war 文件。这种打包方式主要用于 Web 应用程序的部署。

如果你的项目是一个 Web 应用，需要部署到 Servlet 容器中运行，那么你应该将 packaging 设置为 war。

除了 jar 和 war 之外，Maven 还支持其他打包方式，如 pom（用于聚合项目，本身不产生任何构建输出）、ear（用于企业应用归档）、maven-plugin（用于 Maven 插件）等。你可以根据项目的实际需求选择合适的打包方式。

在 Maven 的 pom.xml 文件中，你可以通过 <packaging> 标签来指定项目的打包方式。例如：

xml

<project>  
  ...  
  <packaging>war</packaging>  
  ...  
</project>

4 基于 IDEA 进行 Maven 工程构建

4.1 构建概念

Maven 是一个跨平台的项目管理工具，主要服务于 Java 平台的项目构建和依赖管理。它提供了一个标准化的构建生命周期模型，自动化地完成项目的编译、测试、打包、发布以及部署等工作。Maven 通过约定，规定了源代码、编译后的代码以及其他资源的存放目录，使项目结构更加清晰和统一。

4.2 构建过程

Maven 的构建过程主要包括以下几个步骤：

清理项目：首先，Maven 会清理掉上一次构建生成的文件，确保构建环境是干净的。
编译项目：接着，Maven 会编译项目的源代码，生成编译后的字节码文件。
测试项目：然后，Maven 会运行项目的单元测试，确保代码的质量和功能的正确性。
生成测试报告：测试完成后，Maven 会生成测试报告，展示测试的结果和相关信息。
打包项目：随后，Maven 会将编译后的代码和相关资源打包成特定的格式，如 jar 或 war 包。
部署项目：最后，Maven 可以将打包好的项目部署到指定的服务器上，供其他人或系统使用。

在整个构建过程中，Maven 都遵循着高度自动化、跨平台、可重用组件和标准化的原则，大大提高了项目构建的效率和质量。

此外，Maven 还通过 pom.xml 文件来管理项目的构建信息和依赖关系。在这个文件中，我们可以配置项目的基本信息、依赖的 jar 包、插件以及编译选项等。Maven 会根据这些信息来自动下载所需的 jar 包，并统一管理它们之间的依赖关系。

4.3 构建命令

Maven 项目构建过程中常用的命令主要包括：

mvn clean：这个命令用于清理项目。它会删除 target 目录及其内容，target 目录是 Maven 构建生命周期中默认的输出目录，存放着项目经过编译生成的字节码文件和测试报告等。执行这个命令可以确保构建环境是干净的，避免上一次构建产生的文件影响当前的构建过程。
mvn compile：这个命令用于编译项目的源代码。它会将 src/main/java 目录下的 Java 文件编译成字节码文件，并输出到 target/classes 目录下。如果项目中引用了其他的 jar 包，Maven 会根据 pom.xml 文件中的配置依赖，先从本地仓库中查找这些 jar 包，如果本地不存在，则会联网到 Maven 的中央仓库中查找并下载。
mvn test：这个命令用于运行项目的单元测试。它会执行 src/test/java 目录下的测试代码，并生成测试报告。测试报告通常包括测试的结果、覆盖率等信息，有助于开发者了解代码的质量和功能的正确性。
mvn package：这个命令用于打包项目。它会根据 pom.xml 文件中配置的打包方式（如 jar 或 war），将编译后的代码和相关资源打包成一个文件。打包后的文件通常包括项目的元数据、依赖的 jar 包以及项目的字节码文件等，可以直接部署到服务器或分发给其他用户使用。
mvn install：这个命令用于将项目打包后的文件安装到本地仓库中。本地仓库是 Maven 用于存储和管理 jar 包的地方，通过执行这个命令，其他 Maven 项目就可以引用当前项目作为依赖了。

除了以上常用的命令外，Maven 还提供了其他一些命令，如 mvn archetype:generate 用于按照提示创建项目目录和生成基本的 pom.xml 文件，mvn version:display-dependency-updates 用于显示可用的依赖更新等。这些命令可以根据项目的具体需求进行选择和使用。

在使用 Maven 命令时，通常需要在项目的根目录下打开命令行窗口（如 CMD 或 Terminal），然后输入相应的命令并执行。Maven 会根据 pom.xml 文件中的配置信息和当前命令的要求，自动完成项目的构建过程。

5 基于 IDEA 进行 Maven 依赖管理

5.1 依赖管理概念

Maven 依赖管理（Dependency Management）是 Maven 项目管理工具中的一个核心特性。它集中管理项目中所有的依赖关系信息，确保项目能够正确地获取和使用所需的库和组件。

在 Maven 中，依赖关系是通过在项目的 pom.xml 文件中声明来实现的。每个依赖都包含三个基本元素：groupId、artifactId 和 version，这三个元素共同构成了依赖的唯一标识符（GAV）。通过指定这些元素，Maven 能够准确地定位并下载所需的依赖项。

Maven 依赖管理还支持传递性依赖。这意味着如果一个项目依赖于某个库，而这个库又依赖于其他库，那么 Maven 会自动处理这些传递性依赖，将它们一并下载到项目中。这不仅简化了依赖管理的复杂性，还确保了项目所需的所有依赖都能被正确地获取和使用。

此外，Maven 还提供了依赖冲突解决机制。当项目中存在多个版本相同的依赖时，Maven 会根据一定的规则（如依赖路径最短者优先、声明顺序优先等）来选择使用哪个版本的依赖，从而避免版本冲突导致的问题。

Maven 依赖管理为 Java 项目的构建和部署提供了强大的支持。它简化了依赖管理的过程，降低了出错的可能性，提高了开发效率。同时，通过集中管理和自动处理依赖关系，Maven 还确保了项目的稳定性和可维护性。

5.2 scope

在使用 Maven 进行 Java 项目管理时，“scope”通常指的是依赖的作用域，它定义了依赖在项目的不同生命周期阶段中的可用性和可见性。

具体来说，Maven 中的依赖作用域决定了依赖项在项目构建的不同阶段（如编译、测试、运行等）中的有效性。常见的依赖作用域包括：

compile：这是默认的作用域，表示依赖在编译、测试和运行阶段都是可用的。
test：表示依赖只在测试阶段可用，如 JUnit 这样的测试框架就应当设置为 test 作用域。
runtime：表示依赖在编译阶段不需要，但在测试和运行时需，如 MySQL。
provided：表示依赖在编译和测试阶段可用，但在运行时由 JDK 或容器提供，不需要打包，如 Servlet。
system：与 provided 类似，但依赖的 jar 包需要显式提供系统路径。

5.3 Build 构建配置

5.3.1 自定义命名 jar 包

在 Maven 中，如果你想自定义生成的 jar 包的名称，你可以通过修改 pom.xml 文件中的 build 部分的 finalName 元素来实现。finalName 元素用于指定构建过程中生成的 jar 或 war 等文件的名称。

下面是一个示例，展示了如何在 pom.xml 中自定义 jar 包的名称，my-custom-jar-name 是你想要给 jar 包命名的名称。当 Maven 执行 package 生命周期阶段时，它会生成一个名为 my-custom-jar-name.jar 的文件：

xml

<project>  
    ...  
    <build>  
        <finalName>my-custom-jar-name</finalName>  
        ...  
    </build>  
    ...  
</project>

另外，如果你想要根据项目的版本或其他属性动态地生成 jar 包名称，你可以在 finalName 中使用 Maven 的属性，jar 包的名称将基于 projectName 和 projectVersion 属性的值动态生成。如果项目的版本是 1.0.0，那么生成的 jar 包名称将会是 my-project-1.0.0.jar。例如：

xml

<project>  
    ...  
    <properties>  
        <projectName>my-project</projectName>  
        <projectVersion>${project.version}</projectVersion>  
    </properties>  
    ...  
    <build>  
        <finalName>${projectName}-${projectVersion}</finalName>  
        ...  
    </build>  
    ...  
</project>

请注意，当你使用自定义的 finalName 时，Maven 可能不会自动将生成的 jar 包添加到本地仓库中，因为 Maven 期望 jar 包的名称与 artifactId 和 version 属性匹配。如果你需要将自定义命名的 jar 包安装到本地仓库，你可能需要使用 mvn install:install-file 命令手动安装它。

5.3.2 自定义打包规则

在 Maven 项目中，自定义打包资源规则通常涉及到配置 resources 元素，该元素位于 pom.xml 文件的 build 部分。resources 元素用于指定项目资源文件的位置以及它们如何被打包到最终构建产物中。

默认情况下，Maven 会打包 src/main/resources 目录下的所有资源文件到 jar 或 war 包中。但是，你可以通过自定义 resources 配置来扩展或覆盖这些默认行为。

以下是一些自定义打包资源规则的常见方法：

你可以通过添加额外的 resource 元素来指定 Maven 应该打包的其他资源目录。例如，如果你想将 src/main/my-resources 目录下的文件也打包到 jar 包中，你可以这样配置：

xml

<project>  
    ...  
    <build>  
        ...  
        <resources>  
            <resource>  
                <directory>src/main/resources</directory>  
            </resource>  
            <resource>  
                <directory>src/main/my-resources</directory>  
            </resource>  
        </resources>  
        ...  
    </build>  
    ...  
</project>

过滤资源文件

Maven 允许你使用属性替换来过滤资源文件。这通常用于将构建相关的属性（如版本号）注入到资源文件中。你可以通过配置 filtering 元素来启用过滤：

xml

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

然后，你可以在资源文件中使用 ${propertyName} 占位符，并在 Maven 构建时通过 -DpropertyName=value 参数或 pom.xml 中的 <properties> 元素提供这些属性的值。

你可以使用 includes 和 excludes 元素来指定应该包含或排除哪些文件或目录。这对于仅打包特定类型的文件或排除不需要的文件特别有用。

例如下面的示例中，所有 XML 和 properties 文件都将被包含，但所有以 test 结尾的 XML 文件将被排除。

xml

<project>  
    ...  
    <build>  
        ...  
        <resources>  
            <resource>  
                <directory>src/main/resources</directory>  
                <includes>  
                    <include>**/*.xml</include>  
                    <include>**/*.properties</include>  
                </includes>  
                <excludes>  
                    <exclude>**/*test*.xml</exclude>  
                </excludes>  
            </resource>  
        </resources>  
        ...  
    </build>  
    ...  
</project>

使用 build-helper-maven-plugin 插件

对于更复杂的资源打包需求，你可以考虑使用 build-helper-maven-plugin 插件。这个插件提供了一些额外的目标（goals），可以帮助你更灵活地处理资源文件。例如，你可以使用它的 add-resource 目标来添加额外的资源目录。

通过自定义 resources 配置，你可以精确地控制 Maven 项目中哪些资源文件应该被打包到最终的构建产物中。这对于确保构建产物中包含正确的资源文件以及排除不需要的文件非常有用。

5.4 Maven 依赖传递机制

Maven 的依赖传递是 Maven 的核心机制之一，它极大地简化了 Maven 的依赖配置。在 Maven 项目中，一个项目可能依赖于另一个项目，而被依赖的项目又可能依赖于其他项目，这种依赖关系可以形成一个依赖链。Maven 的依赖传递机制允许用户只需在 POM 文件中定义直接依赖，而无需定义任何间接依赖。Maven 会自动读取当前项目各个直接依赖的 POM，将那些必要的间接依赖以传递性依赖的形式引入到当前项目中。

具体来说，当项目 A 依赖于项目 B，而项目 B 又依赖于项目 C 时，尽管项目 A 并没有直接声明对项目 C 的依赖，但由于依赖传递机制，项目 C 的依赖会被自动引入到项目 A 中。这种机制确保了项目 A 能够正常运行，因为它能够获取到所有必要的依赖。

然而，依赖传递也可能导致依赖冲突的问题。当多个直接依赖引入了相同但不同版本的间接依赖时，Maven 需要决定使用哪个版本的依赖。

5.5 Maven 依赖冲突及解决方案

Maven 的依赖冲突通常发生在项目中引入了多个具有相同 groupId 和 artifactId 但不同 version 的依赖时。这些依赖可能由不同的直接依赖引入，也可能由间接依赖引入，导致 Maven 在构建项目时不知道应该使用哪个版本的依赖。

依赖冲突可能会导致以下问题：

构建错误：当 Maven 无法解析依赖冲突时，可能会导致构建失败。
运行时错误：即使构建成功，依赖冲突也可能导致运行时出现类找不到或方法找不到的错误。
不可预期的行为：不同版本的依赖可能包含不同的功能或修复了不同的 bug，依赖冲突可能导致项目行为不可预期。

解决 Maven 依赖冲突的方法主要有以下几种：

使用依赖树分析：通过运行 mvn dependency:tree 命令，可以查看项目的依赖树，找出存在冲突的依赖。在输出中，可以看到哪些依赖被排除了（omitted for conflict），以及由于哪个依赖而被排除。
排除依赖：在 POM 文件中，可以使用 <exclusions> 标签排除某个依赖的特定传递性依赖。这可以防止不需要的依赖被引入，从而解决依赖冲突。
依赖版本锁定：通过指定依赖的特定版本，可以确保项目中使用的都是预期版本的依赖。这可以通过在 POM 文件中显式声明依赖版本来实现。
使用依赖管理：在父 POM 或依赖管理 POM 中，可以使用 <dependencyManagement> 标签来统一管理依赖的版本。这样，即使子模块或其他依赖声明了不同的版本，Maven 也会使用 <dependencyManagement> 中指定的版本。
优化依赖关系：尽量减少不必要的依赖，避免引入过多的间接依赖。同时，对于重要的依赖，可以考虑将其升级为直接依赖，以便更好地控制其版本。

在解决依赖冲突时，需要注意以下几点：

优先解决直接的、重要的依赖冲突，以避免影响项目的核心功能。
在修改 POM 文件后，重新运行依赖树分析以确保问题已解决。
在进行依赖版本升级时，要注意新版本可能带来的兼容性问题，最好先在测试环境中验证。

6 Maven 工程继承和聚合关系

Maven 工程的继承和聚合是两个不同的概念，它们各自有独特的目的和功能。

继承：

在 Maven 中，继承的主要目的是消除重复配置。通过定义一个父 POM（Project Object Model），子模块可以继承父 POM 中定义的插件、依赖、属性等配置。这样，当多个子模块需要共享相同的配置时，就可以避免在每个子模块的 POM 中重复配置。继承关系通过子模块 POM 中的 <parent> 标签来定义，指向父 POM 的位置。

聚合：

聚合的主要目的是快速构建项目。在 Maven 中，可以定义一个聚合模块，它将多个子模块聚合在一起。通过在聚合模块的 POM 中添加 <modules> 标签，并列出子模块的相对路径，Maven 就可以一次性构建所有子模块，而不需要逐个构建。这大大加快了构建速度，特别是在大型多模块项目中。

需要注意的是，尽管继承和聚合在 Maven 中经常一起使用，但它们之间并没有直接的依赖关系。一个 POM 可以是聚合 POM，也可以是父 POM，或者同时是两者。在实际项目中，为了方便管理，通常会看到一个 POM 同时作为聚合 POM 和父 POM 使用。

此外，无论是聚合还是继承，父模块的 POM 文件中的 <packaging> 元素的值都应该是 pom。这是因为 Maven 规定只有包装类型为 pom 的模块才能被其他模块继承和聚合。如果不指定 <packaging> 元素，默认值为 jar，这将导致 Maven 无法正确识别和处理继承和聚合关系。

7 了解 Maven 仓库之间的关系和优先级

Maven 仓库之间的关系和优先级是 Maven 依赖管理中的重要概念。在 Maven 中，仓库主要分为本地仓库、远程仓库和中央仓库。这些仓库在 Maven 构建过程中扮演着不同的角色，并且它们之间存在一定的优先级关系。

首先，本地仓库是 Maven 用于存储所有构件（如 jar 包、插件等）的默认位置。当 Maven 需要某个构件时，它首先会在本地仓库中查找。如果本地仓库中没有该构件，Maven 就会去远程仓库中查找。

远程仓库是指除了本地仓库以外的其他仓库，包括中央仓库和私有仓库等。中央仓库是 Maven 官方提供的公共仓库，包含了大量的开源构件。私有仓库则是企业或个人自己搭建的仓库，用于存储内部使用的构件。

在 Maven 中，仓库的优先级顺序大致如下：

本地仓库：Maven 首先会在本地仓库中查找所需的构件。如果找到，则直接使用；否则，进入下一步。
中央仓库：如果本地仓库中没有所需构件，Maven 会尝试从中央仓库中下载。中央仓库是 Maven 默认的远程仓库，包含了大量的开源构件。
私有仓库：除了中央仓库外，Maven 还可以配置其他远程仓库，如私有仓库。这些仓库的优先级取决于它们在 Maven 配置文件（如 settings.xml）中的配置顺序。一般来说，私有仓库会配置在中央仓库之前，以便优先使用内部构件。
镜像仓库：在某些情况下，为了提高访问速度或解决网络问题，Maven 可以配置镜像仓库来替代中央仓库或其他远程仓库。镜像仓库与原始仓库具有相同的内容，但访问地址可能不同。当 Maven 尝试从原始仓库获取构件时，如果配置了镜像仓库，则会优先从镜像仓库中获取。

在 Maven 的依赖管理中，依赖的传递性和冲突解决也是重要的概念。依赖传递性指的是当一个项目依赖另一个项目时，被依赖项目的依赖也会被自动引入。而依赖冲突则可能发生在多个依赖引入相同但不同版本的构件时，Maven 会根据一定的规则（如第一声明者优先、路径近者优先等）来解决这些冲突。

Maven 教程 ​

1 Maven 简介 ​

2 Maven 安装和配置 ​

3 基于 IDEA 创建 Maven 工程 ​

3.1 GAV ​

3.2 packaging ​

4 基于 IDEA 进行 Maven 工程构建 ​

4.1 构建概念 ​

4.2 构建过程 ​

4.3 构建命令 ​

5 基于 IDEA 进行 Maven 依赖管理 ​

5.1 依赖管理概念 ​

5.2 scope ​

5.3 Build 构建配置 ​

5.3.1 自定义命名 jar 包 ​

5.3.2 自定义打包规则 ​

5.4 Maven 依赖传递机制 ​

5.5 Maven 依赖冲突及解决方案 ​

6 Maven 工程继承和聚合关系 ​

7 了解 Maven 仓库之间的关系和优先级 ​