一、Maven 仓库
在 Maven 中,任何一个依赖、插件或者项目构建的输出,都可以称之为构件. Maven 在某个统一的位置存储所有项目的共享的构件,这个统一的位置,我们就称之为仓库.(实际上仓库就是存放依赖和插件的地方）
Maven 仓库的分类如下:
1、本地仓库
Maven 的本地仓库,在安装 Maven 之后并不会创建,它是在第一次执行 Maven 命令的时候才被创建.
Maven 本地仓库的默认位置: 无论是 Windows 还是 Linux ,在用户的目录下都有一个 .m2/repository/ 的仓库目录, 这就是 Maven 仓库的默认位置.
如果不想使用默然的仓库,如何更改 Maven 默认的本地仓库的位置?
找到 Maven 的安装目录,打开 /conf/settings.xml ,加入如下配置即可
2、远程仓库
- 中央仓库: 官方存放依赖包和插件的仓库
- 私服: 各个公司或者是组织机构搭建的仓库,供局域网内使用
- 其它公共库: 大型互联网公司或者是非盈利机构维护的仓库,例如:阿里云镜像仓库等
安装好 Maven 后,如果不执行任何 Maven 命令,本地仓库的目录是不存在的.当用户输入第一条 Maven 命令之后, Maven 才会创建本地仓库,然后根据配置和需要,从远程仓库下载构件至本地仓库.由于原始的本地仓库是空的, Maven 就至少需要一个可用的远程仓库,才能在执行 Maven 命令的时候下载需要的构件.中央仓库是默认的远程仓库, Maven 的安装目录自带了默认的远程仓库(中央仓库)的配置.
找到 $M2_HOME/lib/maven-model-builder-3.0.jar 文件
解压这个 jar 包
在 org/apache/maven/model/pom-4.0.0.xml 配置文件中存在如下配置,里面定义了依赖和插件的相关的远程仓库地址
这个文件是所有 Maven 项目都会继承的超级 POM .也就是说如果我们没有配置任何的远程仓库的情况下,执行 Maven 命令,如果本地仓库中不存在你需要的依赖和插件,默认就会去上面的远程仓库(https://repo.maven.apache.org/maven2)中寻找.
3、远程仓库的认证
大部分无需验证就可直接访问,但是出于安全可以配置仓库用户名和密码,所以需要认证.配置认证信息和配置仓库信息不同,仓库信息可以直接配置在 POM 文件中,但是认证信息必须配置在 settings.xml 文件中.这是因为 POM 往往被提交代码仓库供所有成员访问,而 settings.xml 一般只放在本机,所以更安全. id 必须和 POM 中需要认证的 Repository 元素的 id 完全一致,正是这个 id 将认证信息和仓库配置联系在一起.
<servers>
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
</servers>
二、Maven 的生命周期
Maven 有三套生命周期,它们之间是相互独立的,它们分别是 clean、default、site
- clean: 在进行真正的构建之前进行一些清理工作.
- default: 构建的核心部分,主要编译、测试、打包、部署等等.
- site: 生成项目报告,站点,发布站点.
1、clean
clean 包括 mvn pre-clean、clean、post-clean 三个阶段
- mvn pre-clean 清理前期需要完成的工作
- mvn clean 将之前编译生成的 target 目录清除
- mvn post-clean 执行一些清理后的工作
注意:如果执行 mvn post-clean,那么 mvn pre-clean、mvn clean 都会被运行,这是 Maven 很重要的一个规则,可以大大简化命令行的输入.
2、default
default 是 Maven 最重要的生命周期,绝大部分工作都发生在这个生命周期中
- validate
- generate-sources
- process-sources
- generate-resources
- process-resources 复制并处理资源文件,至目标目录,准备打包
- compile 编译项目的源代码
- process-classes
- generate-test-sources
- process-test-sources
- generate-test-resources
- process-test-resources 复制并处理资源文件,至目标测试目录
- test-compile 编译测试源代码
- process-test-classes
- test 使用合适的单元测试框架运行测试,这些测试代码不会被打包或部署
- prepare-package
- package 接受编译好的代码,打包成可发布的格式,如 jar、war
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install 将包安装至本地仓库,以让其它项目依赖
- deploy 将最终的包复制到远程的仓库,以让其它开发人员与项目共享
执行某一个命令的时候,前面的所有阶段都会执行,例如执行 mvn install 的时候, compile、test、package 等阶段都会被执行
3、site
- pre-site 执行一些需要在生成站点文档之前完成的工作
- site 生成项目的站点文档
- post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
- site-deploy 将生成的站点文档部署到特定的服务器上
三、Maven 插件
Maven 的核心文件很小,主要的任务都是由插件来完成.定位到：%本地仓库%orgapachemavenplugins ,可以看到一些下载好的插件
1、插件的目标 (Plugin Goals)
一个插件通常可以完成多个任务,每一个任务就叫做插件的一个目标.如执行 mvn install 命令时,调用的插件和执行的插件目标如下
2、将插件绑定到生命周期
Maven 的生命周期是抽象的,实际需要插件来完成任务,这一过程是通过将插件的目标 (goal) 绑定到生命周期的具体阶段 (phase) 来完成的.
例如将 maven-compiler-plugin 插件的 compile 目标绑定到 default 生命周期的 compile 阶段,完成项目的源代码编译.
Maven 对一些生命周期的阶段（phase）默认绑定了插件目标,因为不同的项目有 jar、war、pom 等不同的打包方式,因此对应的有不同的绑定关系,其中针对 default 生命周期的 jar 包打包方式的绑定关系如下
第二列中,冒号后面即是绑定的插件目标,冒号前面是插件的前缀(prefix),是配置和使用插件的一种简化方式.
3、自定义绑定
用户可以根据需要将任何插件目标绑定到任何生命周期的阶段, 例如将 maven-source-plugin 的 jar-no-fork 目标绑定到 default 生命周期的 package 阶段, 这样,以后在执行 mvn package 命令打包项目时,在 package 阶段之后会执行源代码打包,生成如 ehcache-core-2.5.0-sources.jar 形式的源码包.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>attach-source</id>
<phase>package</phase> <!-- 要绑定到的生命周期的阶段 -->
<goals>
<goal>jar-no-fork</goal> <!-- 要绑定的插件的目标 -->
</goals>
</execution>
</executions>
</plugin>
</plugins>
……
</build>
四、镜像
如果仓库 X 可以提供仓库 Y 存储的所有内容,那么就可以说 X 是 Y 的一个镜像.例如下面配置的阿里云镜像
<mirror>
<!-- 自定义 id 名, id 不重复即可 -->
<id>nexus aliyun</id>
<!-- 自定义 name 名, name 不重复即可 -->
<name>Nexus aliyun</name>
<!-- 所有访问都使用该镜像仓库 -->
<mirrorOf>central</mirrorOf>
<!-- 阿里云镜像仓库地址 -->
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
<mirrorOf> 标签的值是 central ,表示该配置为中央仓库的镜像,任何对于中央仓库的请求都会转至该镜像.
