Maven笔记

什么是Maven

Maven 是 Apache 开源组织奉献的一个开源项目。Maven 的本质是一个项目管理工具，将项目开发和管理过程抽象成一个项目对象模型（POM）。开发人员只需做一些简单的配置，就可以批量完成项目的构建、报告和文档的生成工作。

Maven配置文件

conf/setting.xml

<localRepository>C:\workenv\Java\mvnrepository</localRepository>
<mirror>
  <id>alimaven</id>
  <mirrorOf>central</mirrorOf>
  <name>aliyun maven</name>
  <url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
</mirror>

Maven仓库

本地仓库

远程仓库

<project>
    ...
    <repositories>
        <repository>
            <id>jboss</id>
            <name>JBoss Maven Repository</name>
            <url>http://repository.jboss.com/maven2/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
            <layout>default</layout>
        </repository>
    </repositories>
    ...
</project>

• 私服仓库
  常用Maven 私服搭建方式：
  1、Apache 基金会的 Archiva
  2、JFrog 的 Artifactory
  3、Sonatype 的 Nexus。
• 镜像仓库

<settings>
    ...
    <mirrors>
        <mirror>
            <id>internal-repository</id>
            <name>Internal Repository Manager</name>
            <url>http://192.168.1.207:8080/repository/internal</url>
            <mirrorOf>*</mirrorOf>
        </mirror>
        ...
    </mirrors>

当然，关于 mirrorOf 还有一些特别的配置方式。

<mirrorOf>*</mirrorOf>：匹配所有的远程仓库。
<mirrorOf>external:*</mirrorOf>：匹配所有的远程仓库，使用 localhost、file:// 协议的除外。也就是说，匹配所有非本地的远程仓库。
<mirrorOf>r1，r2</mirrorOf>：匹配指定的几个远程仓库，每个仓库之间用逗号隔开。
<mirrorOf>*，! r1，r2</mirrorOf>：匹配除了指定仓库外的所有仓库，“!”后面的仓库是被排除外的。

• 中央仓库

Maven生命周期和阶段详解

• Maven 中项目的构建生命周期只是 Maven 根据实际情况抽象提炼出来的一个统一标准和规范，是不能做具体事情的。也就是说，Maven 没有提供一个编译器能在编译阶段编译源代码。所以 Maven 只是规定了生命周期的各个阶段和步骤，具体事情，由集成到 Maven 中的插件完成。
• Maven 在生命周期的每个阶段都设计了插件接口。用户可以在接口上根据项目的实际需要绑定第三方的插件，做该阶段应该完成的任务，从而保证所有 Maven 项目构建过程的标准化。当然，Maven 对大多数构建阶段绑定了默认的插件，通过这样的默认绑定，又简化和稳定了实际项目的构建。
• 从插件本身来说，一个插件可以实现生命周期多个阶段的任务，比如 maven-dependency-plugin 就可以实现十多个功能：分析项目的依赖功能；列出项目的依赖树；分析依赖的来源等。为方便指定执行插件的某个功能，将插件的每个功能叫目标。这样就可以实现在哪个阶段，执行哪个插件，达到哪个目标。比如“dependency:analyze”，表示 maven-dependency-plugin 的分析目标；“dependency:tree”表示 maven-dependency-plugin 列出依赖的目标。
• Maven 拥有三套独立的生命周期，它们分别是 clean、default 和 site。clean 生命周期的目的是清理项目；default 生命周期的目的是构建项目；site 生命周期的目的是建立项目站点。每个生命周期又包含了多个阶段。这些阶段在执行的时候是有固定顺序的。后面的阶段一定要等前面的阶段执行完成后才能被执行。

详细阶段定义

Maven有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，初学者容易将Maven的生命周期看成一个整体，其实不然。这三套生命周期分别是：

• ① Clean Lifecycle 在进行真正的构建之前进行一些清理工作。Clean生命周期一共包含了三个阶段：
  1、pre-clean 执行一些需要在clean之前完成的工作
  2、clean 移除所有上一次构建生成的文件
  3、post-clean 执行一些需要在clean之后立刻完成的工作
• ② Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。
  1、validate
  2、generate-sources
  3、process-sources
  4、generate-resources
  5、process-resources 复制并处理资源文件，至目标目录，准备打包
  6、compile 编译项目的源代码
  7、process-classes
  8、generate-test-sources
  9、process-test-sources
  10、generate-test-resources
  11、process-test-resources 复制并处理资源文件，至目标测试目录
  12、test-compile 编译测试源代码
  13、process-test-classes
  14、test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署
  15、prepare-package
  16、package 接受编译好的代码，打包成可发布的格式，如 JAR
  17、pre-integration-test
  18、integration-test
  19、post-integration-test
  20、verify
  21、install 将包安装至本地仓库，以让其它项目依赖。
  22、deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享

那我们在Hello的项目中执行 mvn install 命令，通过日志看看中间经历了什么？

通过日志我们发现，其实执行mvn install，其中已经执行了compile 和 test 。
总结：不论你要执行生命周期的哪一个阶段，maven都是从这个生命周期的开始执行
插件：每个阶段都有插件（plugin），看上面标红的。插件的职责就是执行它对应的命令。

• ③ Site Lifecycle 生成项目报告，站点，发布站点。
  1、pre-site 执行一些需要在生成站点文档之前完成的工作
  2、site 生成项目的站点文档
  3、post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
  4、site-deploy 将生成的站点文档部署到特定的服务器上

插件同生命周期阶段的绑定

实现生命周期的阶段同插件目标的绑定，一共有两种方式：内置绑定和自定义绑定。

1. 内置绑定
   为了让用户方便使用 Maven，少进行配置甚至不用配置，就需要用 Maven 构建项目。Maven 在安装好后，自动为生命周期的主要阶段绑定很多插件的目标。当用户通过命令或图形界面执行生命周期的某个阶段时，对应的插件目标就会自动执行，从而完成任务。
2. 自定义绑定
   除了 Maven 内置的绑定外，也可以通过pom.xml指定在某个阶段绑定某个插件的某个目标。这样就使得 Maven 在构建项目时能执行更多的任务。

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

插件参数配置

1. 命令行配置参数
   在 Maven 命令中，使用 -D后面接参数名称＝参数值的方式配置目标参数。
2. pom 配置参数
   对于有些参数在项目创建好后，目标每次执行的时候都不需要改变，这时候比较好的方式是把这些值配置到 pom.xml 中，这样就省去每次构建的时候都需要输入的麻烦。

<project>
    ...
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.5.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            ...
        </plugins>
    </build>
    ...
</project>

获取插件信息

1. 在线查找插件
   目前，插件基本上都来源于两处，一个是 Apache；另一个是 Codehaus。因为 Maven 本身就来自 Apache 软件基金会，所有在 Apache 上有很多 Maven 的官方插件，而且每天有很多人在使用这些插件，这些插件都经过了很多项目的实际考验，所以它们比较可靠。
2. 使用 maven-help-plugin 查看插件
   除了通过访问在线文档了解某个插件的详细信息外，还可以借助 maven-help-plugin 插件来获取插件的详细信息。比如，在 CMD 命令行窗口中运行如下命令。
   命令中的 -Dplugin＝site 通过插件的前缀来指定要查看的插件名称，与写成 -Dplugin＝org.apache.maven.plugins:maven-site-plugin:3.6 是一样的意思。
   -Dgoal＝site，指定要查看的目标，名称是 site。
   -Ddetail，表示要查看详细信息。

Mvn help:describe -Dplugin=org.apache.maven.plugins:maven-site-plugin:3.4 -Ddetail

Maven插件的调用和解析

调用插件

maven <插件名称|前缀>:<目标> [-D参数名=参数值 …]

解析插件

同依赖构件一样，插件构件也是基于坐标存储在 Maven 仓库中的。在需要时，Maven 先从本地仓库中查找插件，如果没有，就从远程仓库查找。找到插件后，下载到本地仓库使用。

1. 插件仓库

Maven 会区别对待依赖的远程仓库和插件的远程仓库。以前在 setting 中配置的远程仓库只是 Maven 用来找依赖的，而插件的远程仓库是内置的，一般可以直接在 http://repo1.maven.org/maven2 中找到，要自己单独配置插件的远程仓库的话，需要通过 pluginRepositories→pluginRepository 命令进行配置。

<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <name>Maven Plugin Repository</name>
        <url>http://repo1.maven.org/maven2</url>
        <layout>default</layout>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <releases>
            <updatePolicy>never</updatePolicy>
        </releases>
    </pluginRepository>
</pluginRepositories>

2. 插件默认的 groupId

在使用插件或者在 pom 中配置插件的时候，如果使用的是 Maven 官方插件的话，是可以不指定 groupId 的，因为这些插件的 groupId 都是一样的，都是 org.apache.maven.plugins。

3. 解析插件的版本

4. 解析插件的前缀

maven-metadata.xml

<metadata>
    <plugins>
        <plugin>
            <name>Maven Clean Plugin</name>
            <prefix>clean</prefix>
            <artifactId>maven-clean-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Maven Compiler Plugin</name>
            <prefix>compiler</prefix>
            <artifactId>maven-compiler-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Maven Dependency Plugin</name>
            <prefix>dependency</prefix>
            <artifactId>maven-dependency-plugin</artifactId>
        </plugin>
        ...
    </plugins>
</metadata>

Maven坐标

• groupId
• artifactId
• version
• packaging
  如.jar、.ear、.war、.pom 等
• classifier
  javadoc 和 sources 就是这两个附属构件的 classifier

Maven依赖配置和依赖范围

资源定义

资源的依赖

依赖的配置

pom.xml

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

依赖的范围

依赖的范围，从程序结构和构建阶段两方面来理解，就是用来控制三种 classpath 的关系（编译 classpath、测试 classpath 和运行 classpath）。
1）compile
编译依赖范围。如果在配置的时候没有指定，就默认使用这个范围。使用该范围的依赖，对编译、测试、运行三种 classpath 都有效。
2）test
测试依赖范围。使用该范围的依赖只对测试 classpath 有效，在编译主代码或运行项目的时候，这种依赖是无效的。
3）provided
已提供依赖范围。使用此范围的依赖，只在编译和测试 classpath 的时候有效，运行项目的时候是无效的。比如 Web 应用中的 servlet-api，编译和测试的时候就需要该依赖，运行的时候，因为容器中自带了 servlet-api，就没必要使用了。如果使用了，反而有可能出现版本不一致的冲突。
4）runtime
运行时依赖范围。使用该范围的依赖，只对测试和运行的 classpath 有效，但在编译主代码时是无效的。比如 JDBC 驱动实现类，就需要在运行测试和运行主代码时候使用，编译的时候，只需 JDBC 接口就行。
5）system
系统依赖范围。该范围与 classpath 的关系，同 provided 一样。但是，使用 system 访问时，必须通过 systemPath 元素指定依赖文件的路径。因为该依赖不是通过 Maven 仓库解析的，建议谨慎使用。
6）import
导入依赖范围。该依赖范围不会对三种 classpath 产生实际的影响。它的作用是将其他模块定义好的 dependencyManagement 导入当前 Maven 项目 pom 的 dependencyManagement 中。

传递性依赖

三个项目（A、B 和 C 项目），假设 A 依赖 B，B 依赖 C，这样把 A 对 B 的依赖叫第一直接依赖，B 对 C 的依赖叫第二直接依赖，而 A 对 C 的依赖叫传递依赖（通过 B 传递的）。

依赖的调解

在使用 Maven 自动提供的传递依赖后，可以解决对应的依赖管理，特别是间接依赖管理中遇到的问题。但是，当多个直接依赖都带来了同一个间接依赖，而且是不同版本的间接依赖时，就会引起重复依赖，甚至包冲突的问题。

1. 依赖调解原则
   Maven 依赖调解原则有两个：一个是路径优先原则；另一个是声明优先原则。当路径优先原则搞不定的时候，再使用声明优先原则。
2. 可选依赖

• 在实际项目中，存在一些比较特殊的依赖。比如数据访问层模块对数据库驱动的依赖就比较特殊了。DAO 层要访问数据库的时候，需要加入数据库驱动依赖，而且不同数据库驱动依赖是不一样的。如果在设计 DAO 层的时候，是按跨数据库标准实现的，这就引出了一个新问题，是在 pom.xml 中配置 MySQL 驱动依赖呢？还是配置 Oracle 驱动依赖？或者两个都配置？
• 在实际项目中建议不要使用可选依赖。建议遵循单一职责原则，也就是一个类只有一个功能，不要糅合太多的功能，这样不方便理解、开发和维护。实际项目中，一般对不同数据库的驱动单独创建一个 Maven 工程。其他项目需要基于哪个数据库进行操作的话，引用对应的 Maven 的工程以来就行，用传递依赖引入需要的数据库驱动依赖。

Maven的排除依赖、归类依赖和优化依赖

排除依赖

exclusions

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>${project.build.hibernate.version}</version>
    <exclusions>
        <exclusion>
            <groupId>xxx</groupId>
            <artifactId>xxx</artifactId>
        </exclusion>
    </exclusions>
</dependency>

归类依赖

properties

<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">
    ...

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.build.spring.version>4.2.7.RELEASE</project.build.spring.version>
    </properties>

    <dependencies>
        <!-- spring -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${project.build.spring.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-aop</artifactId>
            <version>${project.build.spring.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>${project.build.spring.version}</version>
        </dependency>
        ...
    </dependencies>
    ...
</project>

优化依赖

查看依赖的相关命令：

• mvn dependency:list，列出所有的依赖列表。
• mvn dependency:tree，以树形结构方式，列出依赖和层次关系。
• mvn dependency:analyze，分析主代码、测试代码编译的依赖。

Maven的六类属性

1）内置属性

在 Maven 中主要有两个常用的内置属性，它们分别是＄{basedir}和＄{version}属性。＄{basedir}表示项目的根目录，也就是包含 pom.xml 文件的目录；＄{version}表示项目的版本。

2）POM 属性

用户可以通过 POM 属性，引用 POM 文件中对应元素的值，比如＄{project.artifactId}就对应 project→artifactId 元素的值。常用的 POM 属性包括以下方面。
＄{project.build.sourceDirectory}：项目的主源码目录，默认是 src/main/java。
＄{project.build.testSourceDirectory}：项目的测试源码目录，默认是 src/test/java。
＄{project.build.directory}：项目构建输出目录，默认是 target。
＄{project.outputDirectory}：项目主代码编译输出目录，默认是 target/classes。
＄{project.testOutputDirectory}：项目测试代码编译输出目录，默认是 target/testclasses。
＄{project.groupId}：项目的 groupId。
＄{project.artifactId}：项目的 artifactId。
＄{project.version}：项目的版本。
＄{project.build.finalName}：项目输出的文件名称，默认为“＄{project.artifactId}-＄{project.version}”。
这些属性都在 pom 中有对应的元素。它们中一些属性的默认值都在超级 pom 中有定义，详细情况可以参考超级 pom.xml。

Maven 的超级 pom 文件在“＄MAVEN_HOME/lib/maven-model-builder-x.x.x.jar”中的“org/apache/maven/model”目录下，文件名为 pom-4.0.0.xml。

3）自定义属性

用户可以在 pom 的 properties 中定义自己的 Maven 属性，然后在后面重复使用，同在前面提到的 SpringPOM 的 pom.xml 中定义的 Spring 的版本信息一样。

4）Settings 属性

Settings 属性同 POM 属性是一样的，可以用以“settings.”开头的属性引用 settings.xml 文件中 XML 元素的值。如使用“＄{settings.localRepository}”指向用户本地仓库的地址。

5）Java 系统属性

所有的 Java 系统属性都可以通过 Maven 属性引用，比如“＄{user.home}”指向的就是用户目录。用户可以通过使用“mvn help:system”命令查看所有的 Java 系统属性

6）环境变量属性

所有的环境变量都可以用以“evn.”开头的 Maven 属性引用。比如，“＄{evn.JAVA_HOME}”就指向引用了 JAVA_HOME 环境变量的值。同查看 Java 系统属性一样，用户可以使用命令“mvn help:system”查看到所有的环境变量。

Maven profile配置管理及激活

profile 的种类

根据 profile 配置的位置不同，可以将 profile 分成如下几种。
1）pom.xml
pom.xml 中声明的 profile 只对当前项目有效。
2）用户 settings.xml
在用户目录下的“.m2/settings.xml”中的 profile，对本机上的该用户的所有 Maven 项目有效。
3）全局 settings.xml
在 Maven 安装目录下 conf/settings.xml 中配置的 profile，对本机上所有项目都有效。

为了不影响其他用户且方便升级 Maven，一般配置自己的 settings.xml，不要轻易修改全局的 settings.xml。同样的道理，一般不需要修改全局 settings.xml 中的 profile。

<project>
    <repositories></repositories>
    <pluginRepositories></pluginRepositories>
    <dependencies></dependencies>
    <dependencyManagement></dependencyManagement>
    <modules></modules>
    <properties></properties>
    <reporting></reporting>
    <build>
        <plugins></plugins>
        <defaultGoal></defaultGoal>
        <resources></resources>
        <testResources></testResources>
        <finalName></finalName>
    </build>
</project>

激活 profile 配置

1. 命令行激活
   用户可以在 mvn 命令行中添加参数“-P”，指定要激活的 profile 的 id。如果一次要激活多个 profile，可以用逗号分开一起激活。
2. Settings 文件显示激活
   如果希望某个 profile 默认一直处于激活状态，可以在 settings.xml 中配置 activeProfiles 元素，指定某个 profile 为默认激活状态。

<settings>
    ...
    <activeProfiles>
        <activeProfile>dev_evn</activeProfile>
    </activeProfiles>
    ...
</settings>

3. 系统属性激活
   可以配置当某个系统属性存在时激活 profile，或配置某个属性的值是什么时候激活。

<profiles>
    <profile>
        ...
        <activation>
            <property>
                <name>profileProperty</name>
                <value>dev</value>
            </property>
        </activation>
    </profile>
</profiles>

4. 操作系统环境激活
   用户可以通过配置指定不同操作系统的信息，实现不同操作系统做不同的构建。

<profiles>
    <profile>
        <activation>
            <os>
                <name>Window XP</name>
                <family>Windows</family>
                <arch>x86</arch>
                <version>5.1.2600</version>
            </os>
        </activation>
    </profile>
</profiles>

5. 文件存在与否激活
   当然，也可以通过配置判断某个文件存在与否来决定是否激活 profile。

<profiles>
    <profile>
        <activation>
            <file>
                <missing>t1.properties</missing>
                <exists>t2.properties</exists>
            </file>
        </activation>
    </profile>
</profiles>

6. 默认激活
   最后，还可以配置一个默认的激活 profile。

<profiles>
    <profile>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
</profiles>

Maven自定义插件

编写 Maven 插件的基本步骤

1）创建 Maven 项目。插件的功能肯定需要编写 Java 类的，所以插件本身就是一个 Maven 项目。当然，相对于以前研究的 Maven 项目，插件项目有它的特殊点：packaging 必须是 maven-plugin 类型，可以通过 maven-archetype-plugin 快速创建一个 Maven 插件项目。

2）编写插件目标。每个插件都至少包含一个目标，每个目标对应一个独立的 Java 类。这里把这种类叫 Mojo 类（对象）。Mojo 类必须继承 AbstractMojo 父类。

3）设置目标的配置点。大部分 Maven 件和它的目标都是可以配置的。根据需要，可以在编写 Mojo 的时候给它设置好可以配置的参数。

4）编写逻辑代码，实现目标功能。用 Java 代码实现插件的功能。

5）处理错误和日志。当 Mojo 运行的时候发生异常时，需要根据情况控制 Maven 的运行状况，并且用代码实现必要的日志输出，为用户提供必要的提示信息。

6）测试插件。编写测试案例，绑定（或命令行）执行插件。

Maven自定义插件的Mojo标记和参数

Archetype插件的介绍和使用

Archetype数据库的介绍和使用

• Archetype 数据库实际上就是 archetype-catalog.xml 文件，里面描述了对应 Archetype 插件的坐标。当使用 maven-archetype-plugin 创建 Maven 项目的时候，如果没有指定具体的插件坐标，maven-archetype-plugin 就会读取 archetype-catalog.xml 中的信息，形成列表供用户选择使用。
• maven-archetype-plugin 能读到的 archetype-catalog.xml 有如下几种。
  1）Interal
  maven-archetype-plugin 内置的 Archetype Catalog，有五六十个 Archetype。
  2）Local
  用户本地的 Archetype Catalog，目录是：用户/.m2/archetype-catalog.xml。默认情况该文件不存在，可以在对应目录下添加。
  3）Remote
  Maven 中央仓库的 Archetype Catalog，具体位置是 http://repo1.maven.org/maven2/archetype-catalog.xml。
  4）File
  指定本地任何位置的 archetype-catalog.xml。
  5）HTTP
  使用 HTTP 协议，指定网络中的远程 archetype-catalog.xml。