Maven 的仓库、周期和插件_maven仓库

优质博文：IT-BLOG-CN

一、Maven 仓库

在Maven的世界中，任何一个依赖、插件或者项目构建的输出，都可以称为构建。Maven在某个统一的位置存储所有项目的共享的构建，这个统一的位置，我们就称之为仓库。任何的构建都有唯一的坐标，即 groupId、artifactId、version组成的坐标，Maven 根据这个坐标定义了构建在仓库中的唯一存储路径，规则如下：

<dependency>
    <groupId>com.yintong.distribute</groupId>
    <artifactId>customermgr</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <type>war</type>
</dependency>
1
2
3
4
5
6

【1】基于groupId准备路径，将配置中的 “.” 转换为路径分隔符 “/” ，例如：com.yintong.distribute转换后：com/yintong/distribute；
【2】基于artifactId准备路径，将artifactId连接在后面：com/yintong/distribute/customermgr；
【3】使用version准备路径，将version连接在后面：com/yintong/distribute/customermgr/0.0.1-SNAPSHOT；
【4】将artifactId于version以分隔符连接字号连接：com/yintong/distribute/customermgr/0.0.1-SNAPSHOT/customermgr-0.0.1-SNAPSHOT；
【5】如果有classifier标签，就需要在第4项后增加分隔符连字号（-）再加上 classifier，如果没有就不用加。
【6】如果有extension标签，则加上 “.” 分隔符和extension，而extension是由packaging决定的：com/yintong/distribute/customermgr/0.0.1-SNAPSHOT/customermgr-0.0.1-SNAPSHOT.jar

至此，我们了解了Maven对于构建存储的细节。Maven仓库分为两大类，分别是本地仓库和远程仓库。Maven通过坐标寻找构建时，首先会查看本地仓库，如果有，就直接使用。如果没有，就回去远程仓库查找，找到会先下载到本地，在使用。如果远程库找不到则报错。

本地仓库： 存在于安装Maven的本地，在第一次执行maven命令时创建，默认路径在用户自己的目录下./m2/repository/下，也可以通过编辑Maven 的配置文件setting.xml中的localRepository标签，来将本地仓库设置为想要的位置。一个构件只有在本地仓库中之后，才能由其他的Maven项目使用。一般通过mvn install命令来构件安装到本地仓库中。

远程仓库： 顾名思义，就是存在于服务器上的仓库。当我们安装好 Maven时，本地仓库中还没有任何构件，此时就需要我们自己安装，以及从远程仓库中下载构建来充实自己的本地仓库了。远程仓库有很多个，其中 Maven默认的远程仓库为中央仓库，该仓库中包含了世界上绝大数流行的开源java构件，以及源码、作者信息、软件配置管理SCM、信息、许可证信息等，也是Maven能做到 “开箱即用” 的最大保证。其余还有一些第三方仓库，如jcenter、Google、阿里云都开设了自己的Maven仓库，有兴趣的读者可以自己寻找对应的资料。

如果有需要，也可以搭建自己的私服，它是一种特殊的远程仓库，假设在局域网内，供组织内使用。有以下好处：
1）、节省自己的外网宽带。大量对外仓库的重复请求会消耗很大的宽带，利用私服代理外部仓库后，可消除对外的重复下载；
2）、加速Maven构建。不停地连接和请求外部仓库是十分耗时的，但查询局域网内的仓库则很快；
3）、可以部署自己专用的构件，或者外部不存在的第三方构建。
4）、提高稳定性，增强控制。Maven构建高度依赖与远程仓库，当Internet 不稳定时，Maven的构建也会变的不稳定，甚至无法构建。而是用私服，由于其中已经缓存了大量的构件，即使么有Internet，Maven也可以正常运行；
5）、降低中央仓库的负荷。

Nexus为常用的Maven私服搭建软件，有兴趣的可以自行查找资料。

二、Maven 生命周期

在Maven出现之前，项目构建的生命周期就已经存在，软件开发人员每天都对项目进行清理、编译、测试、部署。Maven从大量项目和构建工具中学习和反思，总结了高度完善的、易扩展的生命周期，将构建过程中的每一步，都映射到生命周期的每一个环节中。

Maven拥有三套相互独立的声明周期，分别为clean、default和site，每个生命周期包含一些阶段，这些阶段都是有顺序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段，下面会对每个周期包含的阶段进行阐述，并对其中重要的阶段作出注释：

clean周期： 为项目的清理周期，包含pre-clean，clean（清理上一次构建生成的文件），post-clean三个阶段。

default周期： 定义了真正构建时所需要执行的所有步骤，它是三个周期中最核心的部分，包含了如下阶段：validate、initialize、generate-source、process-source（处理项目主资源文件）、generate-resources、process-resource、compile（编译项目的主源码）、process-classes、generate-test-source、process-test-resource、test-compile（编译项目的测试代码）、process-test-classes、test（使用单元测试框架运行测试，测试代码不会被打包或部署）、prepare-package，package（接受编译好的代码，打包成可发布的格式，例如：jar）、preintegration-test、integration-test、post-integration-test、verify、install（将包安装到Maven本地仓库，供本地其他Maven项目使用）、depoly（将最终的包复制到远程仓库，供其他开发人员和Maven项目使用）

site周期： 为基于pom中的信息进行自动构建和发布项目站点，包含pre-site、site（生成项目站点文档）、post-site、site-deploy（将生成的项目站点发布到服务器上）

对于上述未加注释的阶段，根据名称也能猜个大概，若想进一步了解参考：官方文档

当我们使用一个Maven命令，例如：mvn package时，实际执行的是该阶段所属周期从第一个阶段到调用阶段之间的所有阶段，既default周期从validate到package之间的所有阶段。而调用多个周期的命令，如mvn clean install时，则执行的是各个周期对应的第一个到调用阶段之间的所有阶段，既pre-clean、clean，以及default周期的validate到install之间的所有阶段。

三、Maven 插件

Maven生命周期以及其各个阶段，都是抽象出来的概念。其实际的动作都是通过插件来完成的，不同声明周期绑定不同的插件，如clean周期绑定的maven-clean-plugin，site周期绑定的maven-site-plugin，default周期根据不同的阶段绑定了maven-jar-plugin等。Maven核心的东西不过3-4M，一旦在执行任务时没有碰到插件，它就会跑到相应的地方去下载，放到本地仓库中，之后再完成整个过程。

为了能够复用代码，一个插件往往能够完成多个任务。如：maven-dependency-plugin，它能够基于项目依赖做很多事情。它能够分析项目依赖，帮组找出潜在的无用依赖；它能够列出项目的依赖树，帮组分析依赖来源；它能够列出项目所有已解析的依赖，等等。为了每个这样的功能编写一个独立的插件显然是不可取的，因此，这些功能都聚集在一个插件中，通过插件的目标来区分这些功能，如上述的dependency插件的功能就是分别通过mvn dependency:analyze、mvn dependency:tree、mvn dependency：list来调用。

了解插件后，就有一个问题，maven默认的生命周期及阶段，都有对应的插件来执行，但是我们想要做的任务，在默认的阶段里面没有怎么办？这个时候就可以通过自己来选择某个插件的某个目标，在pom的build-plugins中将其绑定到生命周期的某个阶段，然后调用命令执行响应任务，当生命周期经过这个阶段，就会执行绑定的该目标了。比如我们希望混淆项目中的js/css源码，可以通过如下配置来处理：

  <build>
      <plugins>
          <plugin>
              <groupId>net.alchim31.maven</groupId>
              <artifactId>yuicompressor-maven-plugin</artifactId>
              <version>1.3.0</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>compress</goal>
                    </goals>
                    <configuration>
                        <excludes>
                            <exclude>**/*.min.js</exclude>
                            <exclude>**/*.-min.js</exclude>
                        </excludes>
                        <encoding>utf8</encoding>
                        <failOnWarning>false</failOnWarning>
                        <nosuffix>true</nosuffix>
                        <force>true</force>
                        <resources>true</resources>
                        <linebreakpos>-1</linebreakpos>
                    </configuration>
                </execution>
            </executions>
          </plugin>
      </plugins>
  </build>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

这样当我们执行mvn package时，就会执行该插件的compress goal，达到将js/css混淆的目的。

Maven的插件有很多种，除了上述声明周期中提到的阶段对应的插件外，还有各种各样具有各式功能的官方和非官方插件，通过定义绑定的方式能让 Maven项目在构建过程中执行更多更丰富特色的任务。其中，官方提供的插件在 官方插件 中能够找到，里面也有相应的说明信息；需要完成一些特定的任务，官方没有提供，就需要自己去寻找对应功能的插件了，比如上面说的 js/css混淆插件；如果任务比较特殊或本地化，并没有这样的插件，则需要自己去开发对应的插件，比如公司的Maven入库管理插件就是针对公司管理需求来开发的。