你竟然没用 Maven 构建项目？

一年前，当我和小伙伴小龙一起做一个外包项目的时候，受到了严重的鄙视。我那时候还不知道 maven，所以搭建项目用的还是最原始的方式，小龙不得已在导入项目的时候花了很长时间去下载项目依赖的开源类库。

出于对我的尊重，小龙没有破口大骂，而是非常委婉地说了一句：“二哥，你好歹也有一定的知名度了，竟然没用 maven 构建项目，真让我大开眼界啊。”

作为一名富有上进心的程序员，不能忍啊。借此机会，有必要隆重地向大家介绍一下 maven 了。

01、maven 是什么？

不管英文功底好不好，先看看官网给出的介绍语吧：

apache maven is a software project management and comprehension tool. based on the concept of a project object model (pom), maven can manage a project's build, reporting and documentation from a central piece of information.

大致的意思就是说，apache maven 是一个项目管理和自动化构建工具，基于项目对象模型（pom）的概念，可以管理项目的构建、报告以及文档。作为 apache 组织中的一个颇为成功的开源项目，maven 主要服务于基于 java 的项目构建、依赖管理和项目信息管理。

maven 采用了约定优先配置的原则，这些原则如下表所示：

目录	目的
${basedir}	存放 pom.xml 和所有的子目录
${basedir}/src/main/java	存放 java 源代码
${basedir}/src/main/resources	存放项目的资源文件，比如说 log4j.properties
${basedir}/src/test/java	存放测试类
${basedir}/src/test/resources	存放测试用的资源
${basedir}/src/main/webapp	存放 web 前端文件
${basedir}/target	项目打包后的输出目录
${basedir}/target/classes	项目编译后输出目录
~/.m2/repository	默认的 maven 仓库目录（~表示用户目录）

使用约定优先配置带来的最大好处就是项目的目录结构图非常的统一，不同的开发者在开发一个 maven 项目的时候，文件存放位置几乎没有差别，省去了很多不必要的麻烦，有利于促进项目团队的标准化。

我们这个年代非常崇尚开源精神，几乎所有的 java 项目都会借用一些第三方的开源类库，这些类库可以通过依赖的方式引入到项目中来。但随着依赖的增多，版本冲突、依赖臃肿的问题就会接踵而来。手工解决这些问题是十分枯燥的，幸运的是 maven 提供了一个优秀的解决方案，它通过一个三维的坐标（<groupid>、<artifactid>、<version>）来准确地定位每一个开源类库。

另外，我认为 maven 特别优秀的一点是，它把项目依赖的所有开源类库都从远程*仓库下载到了指定的本地仓库中，也就是说，这些开源类库可以在多个项目之间共用，无需重复下载——假如我用 maven 构建项目的话，小龙就不用下载那么多开源类库了，他的本地仓库中可能已经有了——我也就不会被鄙视了。

02、配置 maven 环境

1）安装 maven 之前，先确保电脑上已经安装了 jdk。

2）去 maven 官网下载想要的版本并解压，下载地址为：

3）设置环境变量，主要是 maven_home 和 path。

4）打开命令行，输入 mvn -v 验证 maven 是否配置成功。

5）maven 的 conf 目录下包含了一个非常重要的文件 settings.xml，一般情况下，我倾向于将该文件复制到 ~/.m2/ 目录下——建议你也这么做。

打开该文件，在 <mirrors></mirrors> 节点下添加阿里云的镜像地址（参照下面的代码）。为什么要这么做呢？因为 maven 默认的仓库在不翻强的情况下很难访问到。

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

这里需要注意的是，<mirrorof> 的值有下面四种方式：

• *：匹配所有远程仓库，也就是说任何对于*仓库的请求都会转至该镜像。
• external:*：匹配所有不在本机上的远程仓库。
• repo1,repo2：匹配仓库 repo1 和 repo2，使用逗号分隔多个远程仓库。
• *,!repo：匹配所有远程仓库，repo 除外，使用感叹号将仓库从匹配中排除。

6）在 eclipse 下依次选择菜单 window → show view → other → maven → maven workspace build，查看镜像是否配置成功（我习惯了使用 eclipse，所以请见谅，不过不管使用哪种集成开发环境，思路和步骤都大差不差）。

03、快速创建 maven 项目

为了尽快步入重点，这一小节我会有意的避重就轻，没必要的步骤会略过。

1）在 eclipse 中新建项目的时候选择 maven project。

2）在接下来选择项目类型的时候，选择 maven-archetype-quickstart，如下图所示。

3）然后指定项目参数的时候填写 group id 和 artifact id。

4）项目创建成功后的目录结构图如下图所示。

maven 3 默认使用的依然是 jdk 1.5，不过我们可以为其配置更高版本的 jdk，后面会聊到。

04、详细分析 pom.xml

毫无疑问，maven 项目的灵魂只有一个，那就是 pom.xml 文件，所以接下来我会详细地对其进行分析。

1）项目基本信息

pom.xml 文件的第一部分主要用来描述项目的基本信息。

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

  <groupid>com.cmower</groupid>
  <artifactid>test</artifactid>
  <version>0.0.1-snapshot</version>
  <packaging>jar</packaging>

  <name>test</name>

</project>

①、<project> 是 pom.xml 的根元素，声明了相关的命名空间。

②、<modelversion> 指定了当前项目对象模型（pom）的版本，对于 maven 3.x 来说，该值只能是 4.0.0。

③、<groupid> 定义了项目的组名，这个组往往和项目所在的组织或公司关联。

④、<artifactid> 定义了当前 maven 项目在组中唯一的 id。

⑤、<version> 定义了项目的版本号，snapshot 为快照的意思，也就是说该项目还处于开发阶段。

⑥、<packaging> 定义了项目的打包类型，可选值有 war、jar 等。

⑦、<name> 定义了项目的名称。

2）变量配置信息

pom.xml 文件的第二部分通常用来配置一些变量信息。

<properties>
    <spring.version>5.1.5.release</spring.version>
</properties>

有了变量的配置信息后，可以通过 ${spring.version} 的形式来调用这些配置项。这样做的好处显而易见，当依赖项的版本升级的时候，可以直接修改变量值即可。

3）依赖管理

阿里云的 maven 仓库下有各种各样的第三方类库，换句话说就是，只有你想不到的，没有你找不到的。大多数 maven 项目的依赖项列表都会很长很长，为了便于说明，下面我只列出某些具有特色的。

<dependencies>
    <dependency>
        <groupid>junit</groupid>
        <artifactid>junit</artifactid>
        <version>3.8.1</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupid>org.springframework</groupid>
        <artifactid>spring-core</artifactid>
        <version>${spring.version}</version>
        <exclusions>
            <exclusion>
                <groupid>commons-logging</groupid>
                <artifactid>commons-logging</artifactid>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupid>commons-logging</groupid>
        <artifactid>commons-logging</artifactid>
        <version>1.1.1</version>
    </dependency>
</dependencies>

①、上文中曾提到，<groupid>、<artifactid>、<version> 合起来可以准确地定位一个依赖项。那怎么找到想要的依赖项呢？

第一步，进入 mavenrepository 网站，地址如下：

http://mvnrepository.com

然后在搜索框中输入第三方类库的关键字，比如说「spring-core」，点击「search」按钮，可以查看到该类库的链接导航。

第二步，点击链接进入到「spring-core」的主页，可以看到所有版本的「spring-core」，选择一个使用率最高的。使用率高在一定程度上表明这个版本的类库最稳定，它已经得到了广大程序员的认可。

第三步，进入该版本的主页，只需要左键轻轻地在 「maven」选项卡内点一下，就已经把该类库的 maven 依赖信息复制到粘贴板了（不需要「ctrl+c」，非常的人性化），如下图所示。

第四步，将类库的依赖信息粘贴到 pom.xml 文件的 <dependencies> 节点下，然后按下快捷键「ctrl+s」保存。紧接着，依次展开 test → java resources → libraries → maven dependencies 节点，你可以看到该类库已经悄悄地添加进来了。

②、 <exclusions> 主要用于排除依赖。

有时候，我们引入的依赖中可能会包含一些不想要的依赖包，我们想引入自己想要的，这时候就要用到排除依赖了。

使用 <exclusion> 的时候只需要指定 groupid 和 artifactid 就行了，并不需要 version，这是因为 groupid 和 artifactid 就可以定位某种类型的依赖。

③、 <scope> 用来控制依赖的范围。

test：测试依赖范围。典型的例子是 jnuit，它只有在编译测试代码及运行测试的时候才需要。

compile：编译依赖范围（其实不止是编译，对测试、运行同样有效），缺省项，如果没有指定，就会默认使用该依赖范围。

provided：提供依赖范围。对编译和测试有效，但在运行时候无效。

runtime：运行时依赖范围。对测试和运行有效，但在编译时无效。

ps：如果不知道选哪一种，缺省就对了。

4）构建配置

<build> 元素中包含了执行 maven 构建周期目标所需的插件以及相关的配置。

<build>
       <finalname>test</finalname>
       <plugins>

           <plugin>
               <groupid>org.apache.maven.plugins</groupid>
               <artifactid>maven-compiler-plugin</artifactid>
               <version>2.3.2</version>
               <configuration>
                   <source>${jdk.version}</source>
                   <target>${jdk.version}</target>
               </configuration>
           </plugin>

       </plugins>

       <resources>
           <resource>
               <directory>src/main/java</directory>
               <includes>
                   <include>**/*.xml</include>
               </includes>
           </resource>
       </resources>
</build>

①、<finalname>，打成 jar 包或者 war 包时的名称。上文中曾提到，项目打包后的输出目录为 ${basedir}/target。

②、<plugins> 用于指定项目在构建过程中使用的插件。

• 、、 用于确定使用的插件。
• ，该插件所需要的特殊配置。maven 3 默认使用的是 jdk 1.5，本例中我们使用了 jdk 1.8。

③、<resources> 描述了各个资源在 maven 项目中的具体路径。

• ，资源文件的路径，默认位于 ${basedir}/src/main/resources/ 目录下。
• ，用于指定在构建过程中被处理的资源文件；对应 用于省去不被处理的资源文件。

05、使用 maven 对项目进行清理、编译、测试、打包

1）清理：mvn clean，该命令会删除 target 目录。可以直接在命令行中执行该命令，只需要切换到项目所在的路径下即可。

2）编译：mvn complie，该命令会编译 src/main/java 目录下的源码。同时，maven 还会处理在 src/main/resources 目录下的资源文件，确保它们作为编译的一部分。

不过，很遗憾的是，执行该命令会报错。该命令给出的提示是，查看 [help 1] 给出的地址，我尝试了一下，可以将 mvn complie 命令替换为 mvn compiler:compile 命令执行，结果如下图所示。

编译后可以在 target 目录下查看字节码文件。

3）测试：mvn test，test 命令在运行时，会执行 compile 命令；而之前我们已经执行过一次 compile 命令，为了确保结果的准确性，可以执行 mvn clean test 命令确保测试之前没有残余物，结果如下图所示。

maven 会通过 surefire 插件，使用 pom.xml 文件中的测试提供者（通常是 junit）运行测试。执行 test 命令不仅会运行测试，还会产生报告文件，此时 target 目录下的截图如下：

4）打包：mvn install，该命令会按照 pom.xml 文件中 <packaging> 指定的方式（本例为 jar）对编译结果打包。同时，还会把打包好的文件放到本地的 maven 仓库中，以便其他项目把它当做依赖项使用。命令执行结果如下图所示。

查看本地的 maven 仓库，可以看到刚刚打包好的文件。

06、最后

在 maven 出现之前，流行的构建工具是 ant；在 maven 出现之后，还有一种新兴的构建工具 gradle，它有意选择了和 maven 相反的原则，不会强制使用者遵循刻板的构建周期。

总之，maven 是一款优秀的构建工具，java 项目的开发者很有必要熟练地掌握它。