一、Maven 仓库
在 Maven 的世界中，任何一个依赖、插件或者项目构建的输出，都可以称为构建。Maven 在某个统一的位置存储所有项目的共享的构建，这个统一的位置，我们就称之为仓库。任何的构建都有唯一的坐标，即 groupId、artifactId、version 组成的坐标，Maven 根据这个坐标定义了构建在仓库中的唯一存储路径，规则如下：
1 <dependency>
2 <groupId>com.yintong.distribute</groupId>
3 <artifactId>customermgr</artifactId>
4 <version>0.0.1-SNAPSHOT</version>
5 <type>war</type>
6 </dependency>
【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 默认的远程仓库为中央仓库（http://repo.maven.apache.org/maven2），该仓库中包含了世界上绝大数流行的开源 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>
这样当我们执行 mvn package 时，就会执行该插件的 compress goal，达到将 js/css 混淆的目的。
Maven 的插件有很多种，除了上述声明周期中提到的阶段对应的插件外，还有各种各样具有各式功能的官方和非官方插件，通过定义绑定的方式能让 Maven 项目在构建过程中执行更多更丰富特色的任务。其中，官方提供的插件在 官方插件 中能够找到，里面也有相应的说明信息；需要完成一些特定的任务，官方没有提供，就需要自己去寻找对应功能的插件了，比如上面说的 js/css 混淆插件；如果任务比较特殊或本地化，并没有这样的插件，则需要自己去开发对应的插件，比如公司的 Maven 入库管理插件就是针对公司管理需求来开发的。
----关注公众号，获取更多内容----
