目录

1. Maven简介

1.1 项目管理

1.2 项目构建

1.3 项目构建工具

1.4 Maven的四大特征

1.4.1 依赖管理系统

1.4.2 多模块构建

1.4.3 一致的项目结构

1.4.4 一致的构建模型和插件机制

1.5 Maven模型

 ​编辑

2.maven的安装配置 

2.1 Maven的安装配置

2.1.1检测jdk的版本

2.1.2下载maven

2.1.3配置maven环境变量

2.2 认识maven的目录结构

2.3 Maven的第一个项目

1.  按照约定创建Maven项目目录

2.在pom.xml文件中写入如下内容(不用记忆)

3.在mian-->java--》下边创建java文件

4.cmd下编译并运行

Maven命令的执行方案：

2.4 IDEA对Maven环境的集成，创建Maven的java项目

3. Maven仓库的基本概念

3.1 中央仓库

3.2 私服

3.3 其他公共库

4. Maven环境下构建多模块项目

4.1 创建maven_parent项目

4.2 创建子模块

4.3 设置模块之间的依赖关系

 1.  dao模块​编辑

 2. service模块

3. controller层

4. 启动项目

5. Maven打包操作

6. Maven依赖的基本概念

6.1 依赖的基本配置

6.2 依赖范围

6.3 传递性依赖

7. Maven的生命周期

7.1 生命周期的概念

 7.2 完整的生命周期

1. Maven简介

• 翻译为“专家”，“内行”
• Maven是跨平台的项目管理工具。主要服务于基于Java平台的项目构建，依赖管理和项目信息管理。

• maven最主要体现在两个词上：项目的管理和项目的构建。

• 什么是理想的项目构建？
  • 高度自动化，跨平台，可重用的组件，标准化的流程
• 什么是依赖？为什么要进行依赖管理？
  • 自动下载，统一依赖管理
  • A1.0   依托于  B 2.0  依托于    C3.0

• 有哪些项目信息？
  • 项目名称描述等，开发人员信息，开发者信息等。

1.1 项目管理

        maven给我们整个开发团队找出了一种能够更加科学的去管理我们项目的思想。maven通过使用配置文件的方式使得项目在管理和交接的过程中成本变得非常低。maven提出了一种叫做maven仓库的概念,使得我们可以将第三方和我们需要引用的项目都放置在maven仓库当中。如果其他人或项目组也需要使用,就可以直接通过maven进行配置就行。这样就可以将人员成本、沟通成本等等都进行降低。

        如果还不理解我们举个例子：加入我们现在想做一份菜：糖醋排骨。如果我们想要做这道菜，那么我们首先要先去菜市场买排骨、糖、醋、......，而且在做的时候还要注意使用糖醋的用量等等。那么如果有一个超市，该超市有卖糖醋排骨的料理包，这是不是就能很大的节省我们做饭和买菜的时间开销。其实maven就是这个卖料理包的超市，但是卖的不是料理包,而是一系列的jar包。这样我们在写代码的时候就不需要去其他网站上下载一大堆的jar包。

1.2 项目构建

        构建(build)是每一个程序员都在做的工作。仔细观察我们会发现，除了编写代码，我们每天都有相当一部分时间花在了编译，运行单元测试，生成文档、打包和部署等繁琐和不起眼的工作上，这就是构建。如果我们现在还是手工的做这些事情，那么时间成本就太高了，于是有人用软件的方法让这一系列工作完全自动化。是软件构建完全像流水线一样，只需要一条简单的命令，所有繁琐的步骤就能很快的自动完成。

传统项目和maven项目构建的两种方式

传统项目：

        打开Idea编写源代码和配置文件，对源代码进行编译，可以使用Junit进行单元测试，把项目打成war包，部署到Tomcat服务器中运行。

maven项目：

        maven将项目构建过程进行标准化，每个阶段都可以使用一个命令来完成。

                清理 --> 编译 --> 测试 --> 报告 --> 打包 --> 部署

        好处：

        可以通过命令完成项目构建。（测试：使用mvn tomcat:run的命令来发布运行项目）

        maven对每个构建阶段进行规范，有利于大型团队协作开发。

1.3 项目构建工具

Ant构建

        最早的构建工具，基于IDE,大概是2000年有的，当时最流行的java构建工具，不过他的xml脚本编写风格让xml文件特别大。对工程构建过程中的过程控制的特别好。

Maven [ java ]

        Maven是一个项目管理和整合工具。Maven为开发者提供了一整套完整的生命周期框架。开发团队几乎不用花多长时间就能够自动完成工程的基础构建配置。他填补了Ant的缺点，Maven第一次支持了从网上下载的功能，仍然采用xml作为配置文件格式。Maven专注的是项目依赖，使用java编写。

Gradle

        属于结合以上两个的优势，他继承了Ant的灵活和Maven的生命周期管理，他最终被google作为了Android御用管理工具。他最大的区别是不用XML作为配置文件格式，采用了DSL格式，使得脚本更加简洁。

        目前市面上Ant比较老，所以一般是一些比较传统的软件企业公司使用，Maven使用java编写,是当下大多数互联网公司使用的一种构建工具，中文文档也比较齐全，gradle是用groovy编写，目前比较新的构建工具一些初创互联网公司会使用，以后会有很大的使用空间。

1.4 Maven的四大特征

1.4.1 依赖管理系统

        Maven为java世界引入了一个新的依赖管理系统jar包管理 jar包升级时修改配置文件即可。在java世界中，可以用gropId、artifactId、version组成Coordination(坐标)唯一标识一个依赖。

        任何基于maven构建的项目自身也必须定义这三个属性。

<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.4.5</version>
</dependency>

坐标属性的理解

        Maven坐标为各个组件引入了新秩序，任何一个组件都必须明确定义自己的坐标。

groupId

        定义当前Maven项目隶属的实际项目-公司名称。（jar包所在仓库路径）由于maven中模块的概念，因此一个项目实际往往会被分成多个模块。比如Spring是一个实际的项目，其对应的Maven模块会有很多，比如Spring-croe,spring-webmvc等。

artifactid

        该元素定义实际项目中的Maven模块-项目名称，推荐的做法是使用实际项目名称作为atrifactid的前缀。比如：Spring-bean,Spring-webmvc等。

version

        该元素定义Maven项目当前所处的版本。

        采用依赖管理的好处是

                能够大大减少我们对jar包下载和管理的难度。

        比如项目当中如果有100个jar包，难道我们需要从网上下载这100个jar包吗？显然如果利用maven提供给我们的坐标，就可以很快完成项目的构建。 

1.4.2 多模块构建

        我们在写项目的时候往往需要将 dao service controller 层分离讲一个项目分解为多个模块已经是一种通用的方式。

1.4.3 一致的项目结构

        我们当初在eclipse上边写的项目如果导入到idea上边，那么就会出现很多奇奇怪怪的问题，同理，将idea上边的项目导入到eclipse当中也是一样。究其原因是因为我们在这两个编译器上的项目的目录结构是不一致的。而maven在设计之初的理念就是Conversion over configuration (约定大于配置)。其制定了一套项目目录结构作为标准的java项目结构，解决不同的ida带来文件目录不一致的问题。

1.4.4 一致的构建模型和插件机制

        这一个项目当中我们往往会引入很多插件，比如tomcat服务器或者jetty(嵌入式服务器),为了实现项目组内插件的统一，maven提供了一套机制来包证这要机制的施行。

<plugins>
    <plugin>
        <groupId>org.eclipse.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>9.2.8.v20150217</version>
        <configuration>
	    <httpConnector>
		   <port>80</port>
	    </httpConnector>
	    <stopKey>shutdown</stopKey>
	    <stopPort>9966</stopPort>
        </configuration>
    </plugin>
</plugins>

1.5 Maven模型

2.maven的安装配置 

2.1 Maven的安装配置

2.1.1检测jdk的版本

jdk版本1.7及以上版本

2.1.2下载maven

• • • 地址：Download Apache Maven – Maven
    • 下载地址：Index of /dist/maven/maven-3/3.6.0/binaries
    • 版本：Maven3.6

下载解压到D盘的根目录。

2.1.3配置maven环境变量

        解压后把maven的根目录配置到下同环境变量中Maven_HOME,将bin目录配置到path变量中。

注：maven解压后存放的目录不要包含中文和空格。

编辑环境变量 :（在开始搜索环境变量）

变量名：MAVEN_HOME

变量值：自己的安装目录

编辑系统变量 Path

添加变量值：%MAVEN_HOME%\bin

检验是否安装成功

2.2 认识maven的目录结构

bin：含有mvn运行的脚本

boot：含有plexus-classworlds类加载器框架

conf：含有settings.xml配置文件

lib：含有Maven运行时所需要的java类库

LICENSE.txt, NOTICE.txt, README.txt针对Maven版本，第三方软件等简要介绍

2.3 Maven的第一个项目

1.  按照约定创建Maven项目目录

src下放资源

• src/main/java —— 存放项目的.java文件 
• src/main/resources —— 存放项目资源文件，如spring, mybatis配置文件 
• src/test/java —— 存放所有测试.java文件，如JUnit测试类 
• src/test/resources —— 测试资源文件 
• target —— 项目输出位置 
• pom.xml  所有第三方的引入都在这

2.在pom.xml文件中写入如下内容(不用记忆)

<?xml version="1.0" encoding="UTF-8"?>
<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">
		
    <modelVersion>4.0.0</modelVersion>  <!-- 制定pom模型的版本 -->
	
    <groupId>com.qcby</groupId> <!-- 定义了项目属于那个组，这个组往往和项目所在的组织和公司存在关联 -->
    <artifactId>maven</artifactId><!-- 定义了当前Maven项目组中唯一的ID -->
    <version>1.0-SNAPSHOT</version><!--版本：SNAPSHOT(快照，开发版) alpha(内部测试版) beta(公开测试版) Release | RC (发布版) GA(正常版本) -->
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

        使用name标签声明是一个对用户更友好的项目名称，虽然不是必须的，但是还是推荐为每个pom声明name,以方便信息的交流。

3.在mian-->java--》下边创建java文件

4.cmd下编译并运行

1.修改默认仓库位置

  在D盘根目录创建一个文件夹：maven  后面所有的jar包都在这个包里。

原因：

在配置文件seting.xml文件中：

配置国内的镜像：

<mirrors>
    <mirror>
        <id>alimaven</id>
        <name>aliyun maven</name>
        <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
        <mirrorOf>central</mirrorOf>
   </mirror>
  </mirrors>

Maven命令的执行方案：

win+cmd打开终端

首先进入到桌面创建的项目命令中

1. 编译：

mvn compile

如果编译不成功，可能出现的问题

• 1.不是使用管理员执行dos命名
• 2.JDK环境变量配置有问题,重新配置jdk
• 3.编写代码时，类里边有代码出现

 2.执行main方法

里面写的是路径

mvn exec:java -Dexec.mainClass="com.qcby.Hello"

第一次可能需要下载很多东西，需要很长的时间。

2.4 IDEA对Maven环境的集成，创建Maven的java项目

1. 新建，选择Maven项目，点击下一步。

 右边可选可不选。

2.起名字，点击完成。

这样创建好基本的原生的Maven项目。

这个删掉，无所谓。

3. 创建软件包。

pom.xml内容复制过去

4. 配置Maven环境。在文件-设置里

找到部署-构建工具

这样下载就是利用aliyun下载。

想运行，在下面选择终端。编译，执行。

mvn compile

 或者：

清除，打包，下载

点击compile会帮助打包

3. Maven仓库的基本概念

仓库

        在我们本地（D盘创建了maven文件夹），当然，还下载apache-maven(做仓库管理的)，maven文件夹就是仓库，本地maven仓库。

        在官方的仓库里有所有的公开的仓库， 我们想使用，需要通过apache-maven下载到本地（依赖pom.xml文件，在pom.xml中配置好依赖，就可从官方仓库下载），下载因为是从国外下载的，所以非常慢。

        想快速下载，于是阿里巴巴配置了aliyun镜像，把所有东西都下载到aliyun服务器，于是变成从aliyun下载。

        不对外公开的jar包，搭建到自己的私服当中。

        当第一次运行Maven命令的时候， 你需要Internet链接， 因为它需要从网上下载一些文件。 那么它从哪里下载呢？它是从Maven默认的远程库下载的。 这个远程仓库有Maven的核心插件和可供下载的jar文件。

        当Maven根据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在，则直接使用； 如果本地没有，Maven就会去远程仓库查找，发现需要的构件之后，下载到本地仓库再使用。 如果本地仓库和远程仓库都没有，Maven就会报错。

远程仓库分为三种： 中央仓库，私服, 其他公共库。

中央仓库是默认配置下，Maven下载jar包的地方。

        私服是另一种特殊的远程仓库，为了节省带宽和时间，应该在局域网内架设一个私有的仓库服务器，用其代理所有外部的远程仓库。 内部的项目还能部署到私服上供其他项目使用。

        一般来说，在Maven项目目录下，没有诸如lib/这样用来存放依赖文件的目录。 当Maven在执行编译或测试时，如果需要使用依赖文件，它总是基于坐标使用本地仓库的依赖文件。

        默认情况下， 每个用户在自己的用户目录下都有一个路径名为.m2/repository/的仓库目录。 有时候，因为某些原因（比如c盘空间不足）,需要修改本地仓库目录地址。

        对于仓库路径的修改，可以通过maven 配置文件conf 目录下settings.xml来指定仓库路径

<!-- 设置到指定目录中，路径的斜杆不要写反 -->
<settings>
    <localRepository>D:/maven</localRepository>
</settings>

3.1 中央仓库

        由于原始的本地仓库是空的，maven必须知道至少一个可用的远程仓库，才能执行maven命令的时候下载到需要的构件。中央仓库就是这样一个默认的远程仓库。

        maven-model-builder-3.3.9.jar maven自动的 jar 中包含了一个 超级POM。定义了默认中央仓库的位置。 中央仓库包含了2000多个开源项目，接收每天1亿次以上的访问。

3.2 私服

        私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务， 私服代理广域网上的远程仓库，供局域网内的maven用户使用。 当maven需要下载构件时， 它去私服当中找，如果私服没有， 则从外部远程仓库下载，并缓存在私服上， 再为maven提供。

        此外，一些无法从外部仓库下载的构件也能从本地上传到私服提供局域网中其他人使用配置方式项目pom.xml 配置。

<repositories>
    <repository>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <id>public</id>
        <name>Public Repositories</name>
        <url>http://192.168.0.96:8081/content/groups/public/</url>
    </repository>
    <repository>
        <id>getui-nexus</id>
        <url>http://mvn.gt.igexin.com/nexus/content/repositories/releases/</url>
    </repository>
</repositories>

<mirror>
    <id>nexus-aliyun</id>
    <mirrorOf>central</mirrorOf>
    <name>Nexus aliyun</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>

 contoller是从浏览器和前端进行交互

4.1 创建maven_parent项目

先新建父项目，再在父项目下创建子项目。

注意

 ！！创建好之后，不要忘记Maven的配置文件，因为默认不是自己配置的。

 创建好之后，创建子模块，dao层，service层和controller层。

4.2 创建子模块

1. dao层

         当父Maven配置好，子模块Maven也配置好了。

2. service层-业务相关

与dao层一样的操作。

3. controller层-与web交互，所以选择webapp

注意：别忘了修改如下信息

4.3 设置模块之间的依赖关系

 1.  dao模块

 2. service模块

首先，把service里的pom文件删一些依赖。

除此以外，完成对dao层的依赖。

（加上static，不然没法直接调用。）

3. controller层

        由于现在该项目是个普通的Maven项目（依赖什么就是什么），想用@Controller注解没有。尝试用别的。用servlet。

（    

我的有问题，Maven不选择自己配置的就没问题了。）

4. 启动项目

用Tomcat启动

（可能8080端口不能用，改成80即可） 

         插件引入之后，启动。有一个启动顺序。

        在右侧Maven那里，先启动父级，再启动dao层，然后是service层，最后是Controller层（在生命周期里，install一下）。最后启动Controller层之后，在其下的插件里启动Tomcat。

5. Maven打包操作

       对于企业级项目，无论是进行本地测试，还是测试环境测试以及最终的项目上线，都会涉及项目的打包操作。对于每个环境下的项目打包，对应的项目所需要的配置资源都会有所区别，实现打包的方式有很多种，可以通过ant，或者通过idea 自带的打包功能实现项目打包，但当项目很大并且需要的外界配置很多时，此时打包的配置就会异常复杂，对于maven 项目，我们可以用过 pom.xml 配置的方式来实现打包时的环境选择，相比较其他形式打包工具，通过maven 只需要通过简单的配置，就可以轻松完成不同环境下项目的整体打包。

        使用idea创建项目，目录结构可能会缺失，需要通过手动添加对应的目录结构

1.首先创建maven的web项目

清空和修改pom文件

2. 添加 Java 源文件夹

选择项目的 main 文件夹，右键选择New，选择Directory

3. 添加资源文件夹

步骤如上，创建文件夹，命名为 resources

4. 添加对应的文件夹目录，及添加不同环境下对应的配置文件。（本地环境、测试环境、正式环境）

 5. 在pom文件当中添加打包环境

<!-- 打包环境配置 开发环境 测试环境 正式环境 -->
<profiles>
  <profile>
    <id>dev</id>
    <properties>
      <env>dev</env>
    </properties>
    <!-- 未指定环境时，默认打包dev环境 -->
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
  </profile>
  <profile>
    <id>test</id>
    <properties>
      <env>test</env>
    </properties>
  </profile>
  <profile>
    <id>product</id>
    <properties>
      <env>product</env>
    </properties>
  </profile>
</profiles>

 6.设置资源文件配置

<!-- 对于项目资源文件的配置放在build中 -->
<resources>
  <resource>
    <directory>src/main/resources/${env}</directory>
  </resource>
  <resource>
    <directory>src/main/java</directory>
    <includes>
      <include>**/*.xml</include>
      <include>**/*.properties</include>
      <include>**/*.tld</include>
    </includes>
    <filtering>false</filtering>
  </resource>
</resources>

7. 打包

6. Maven依赖的基本概念

6.1 依赖的基本配置

根元素project下的dependencies可以包含多个 dependence元素，以声明多个依赖。每个依赖都应

该包含以下元素：

  1. groupId, artifactId, version : 依赖的基本坐标， 对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。

  2. Type： 依赖的类型，大部分情况下不需要声明。 默认值为jar

  3. Scope： 依赖范围（compile,test,provided,runtime,system）

      compile: 编译依赖范围。

            如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测

试、运行三种classpath都有效。

       test: 测试依赖范围。

                使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子就是JUnit，它只有在编译测试代码及运行测试的时候才需要。

       provided: 已提供依赖范围。

               使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍(如：servlet-api)。

       runtime: 运行时依赖范围。

                使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

        system: 系统依赖范围。

                 该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

    4. Optional：标记依赖是否可选

    5. Exclusions： 用来排除传递性依赖。

6.2 依赖范围

        首先需要知道，Maven在编译项目主代码的时候需要使用一套classpath。 比如：编译项目代码的时候需要用到spring-core, 该文件以依赖的方式被引入到classpath中。

        其次， Maven在执行测试的时候会使用另外一套classpath。 如：junit。

        最后在实际运行项目时，又会使用一套classpath， spring-core需要在该classpath中，而junit不需要。

    那么依赖范围就是用来控制依赖与这三种classpath(编译classpath，测试classpath，运行时

classpath)的关系， Maven有以下几种依赖范围：

        Compile 编译依赖范围。 如果没有指定，就会默认使用该依赖范围。 使用此依赖范围的Maven依赖， 对于编译，测试，运行都有效。

        Test： 测试依赖范围。 只在测试的时候需要。比如junit

        Provided： 已提供依赖范围。 使用此依赖范围的Maven依赖，对于编译和测试有效， 但在运行时无效。 典型的例子是servlet-API, 编译和测试项目的需要， 但在运行项目时， 由于容器已经提供， 就不需要Maven重复地引入一遍。

        Runtime： 运行时依赖范围。 使用此依赖范围的Maven依赖，对于测试和运行有效， 但在编译代码时无效。 典型的例子是：jdbc驱动程序， 项目主代码的编译只需要jdk提供的jdbc接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体jdbc驱动。

        System： 系统依赖范围。 一般不使用。

6.3 传递性依赖

   传递依赖机制， 让我们在使用某个jar的时候就不用去考虑它依赖了什么。也不用担心引入多余的依赖。 Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前项目中。

注意： 传递依赖有可能产生冲突！！

冲突场景：

        如果A下同时存在两个不同version的C，冲突！！（选取同时适合A、B的版本）

  <dependencies>
    <dependency>
      <groupId>A</groupId>
      <artifactId>A</artifactId>
      <version>xxx</version>
      <exclusions>
        <exclusion>
          <groupId>C</groupId>
          <artifactId>C</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>B</groupId>
      <artifactId>B</artifactId>
    </dependency>
  </dependencies>
  这里的<exclusions>
  <exclusion>
    <groupId>C</groupId>
    <artifactId>C</artifactId>
  </exclusion>
</exclusions> 来排除冲突的

7. Maven的生命周期

7.1 生命周期的概念

        Maven的生命周期是对所有的构建过程进行抽象和统一。Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，生命周期只是定义了一系列的阶段，并确定这些阶段的执行顺序。而在执行这些阶段时，实际的工作还是由插件来完成的。这种思想与设计模式中的模板方法非常相似。

Maven有三套相互独立的生命周期:

• Clean
  • • clean生命周期的目的是清理项目
• Default
  • • default生命周期的目的是构建项目
• site
  • • site生命周期的目的是建立项目站点。

 7.2 完整的生命周期

        用户在mvn命令后可以指定三个生命周期中的任何阶段，则Maven会按以下逻辑执行：首先会得到该阶段所属生命周期，从该生命周期中的第一个阶段开始按顺序执行，直至该阶段本身。例如执行mvn clean命令会依次执行clean生命周期中的pre-clean阶段及clean阶段。mvn命令后可以指定多个阶段，Maven会按照输入的顺序依次执行，每次执行都会按照之前描述的逻辑执行。

        之前提到实际的工作还是由插件来完成的，这意味着插件需要和阶段绑定起来。Maven已经事先将很多核心插件绑定到对应的阶段，这样用户几乎不用配置就有构建Maven项目。Maven的内置绑定如下：