优质博文: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】基于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>
这样当我们执行mvn package
时,就会执行该插件的compress goal
,达到将js/css
混淆的目的。
Maven
的插件有很多种,除了上述声明周期中提到的阶段对应的插件外,还有各种各样具有各式功能的官方和非官方插件,通过定义绑定的方式能让 Maven
项目在构建过程中执行更多更丰富特色的任务。其中,官方提供的插件在 官方插件 中能够找到,里面也有相应的说明信息;需要完成一些特定的任务,官方没有提供,就需要自己去寻找对应功能的插件了,比如上面说的 js/css
混淆插件;如果任务比较特殊或本地化,并没有这样的插件,则需要自己去开发对应的插件,比如公司的Maven
入库管理插件就是针对公司管理需求来开发的。