Mavan简介
Maven是一个项目管理工具，可以对Java项目进行自动化的构建和依赖管理。
Maven采用了配置文件的形式对项目的名称、版本号、项目依赖等信息进行描述，降低接手的成本，定义好约定俗成的配置准则。
Maven组成
Maven是一个项目管理工具。主要包含了：项目对象模型（POM，Project Object Model），项目生命周期(Project lifecycle)，依赖管理系统和各种插件。
其中插件的主要目的就是各种生命周期中实现相关的目标。
具体如图：
Maven解决的问题
1、项目构建：
项目构建就是完成整个软件项目生产的过程，过程中可以在缩略为3个部分：
-
-
文档和代码的生成（有些项目会使用代码自动生成公管局，比如数据库访问代码的逆向工程）
-
代码的编译、测试和打包
-
将打包好的代码进行分发部署
-
Maven简单来说就是帮助完成了以上过程。
2、项目依赖管理：
在没有依赖管理的阶段，对于所有的代码依赖包需要手动导入，依赖之间可能还存在依赖内部的依赖导入，在此过程中还要校验相关的版本号来避免版本正确。
在一个较大的系统当中去做这些事情是十分困难的。这也是Maven解决的一个重要问题。
有了Maven，我们只要在POM文件中指定依赖包的名称、版本号，Maven就会自动下载、递归下载。
Maven还有一个快照依赖的功能，对于一些正在开发中的依赖包可能会不断更新版本。在使用的时候可能要不断去依赖最新的版本，快照依赖的出现就是能够让你只依赖快照依赖，来确保每一次的依赖版本都是目前的最新版本。
Maven仓库
在Maven中，仓库是一个重要的部分。在开发的过程中，必不可少的需要引入大量的三方库，这些库所在的位置在Maven中就称之为"仓库"。
在Maven中，任何一个依赖、插件或者项目构建的输入都可以称之为"构件"。
Maven当中的仓库就用来管理这些构建。
仓库主要有三种类型：
1、本地仓库(Local)：
本地本机放置构件的位置，Maven从远端仓库下载下来的构建都存放在本地仓库中。
项目会优先在本地仓库中获取自己所依赖的文件。运行 Maven 时，Maven 所需要的任何构件都是从本地仓库获取的，但是如果本地仓库没有，才会选择去远程仓库进行下载。
2、中央仓库(Central)：
Maven中央仓库就是Maven社区提供的仓库，其中包含了大量常用的库。
中央仓库可以通过Maven Central Repository Search 来访问。
3、远程私服(Remote)：
私服一般是指公司内部使用的仓库。它就会尝试从远程仓库中下载构件到本地仓库。如果 Maven 无法连接到远程仓库，将无法正常构建项目。也可以是开发人员自己定义的仓库。如阿里云Mavan仓库都可以定义为远程私服仓库。
在运行过程中3个仓库的访问顺序：
执行Maven 构建命令时：
Step1：在本地仓库中寻找，找不到则进行step2，找到了继续其他操作。
Step2：在中央仓库寻找，若找不到，并且有一个或者多个远程仓库已经设置，则执行步骤4，如果找到了则下载到本地仓库中备用。
Step3：如果远程仓库没有被设置，抛出错误。
Step4：是在远程仓库中寻找依赖的文件，若有则下载到本地备用，若没有则报错，停止。
Macen之间的关系如图：
Maven仓库的创建
Maven本地仓库会在第1次执行Maven命令时创建，本地仓库的保存位置位于%USER_HOME%目录下，当然也可以进行修改。
我们可以尝试执行指令来创建Maven本地仓库：
可以看到，仓库已经开始创建。
查看我们的本地仓库文件：
可以看到已经开始下载。
这也说明Maven已经开始工作了。
Maven项目的创建
在IDEA中创建quick start的模板项目即可：
创建后可以看到我们的项目结构已经按照Maven推荐的结构来生成：
创建后，主要要了解的两个文件：
1、POM文件：
pom.xml文件主要描述了项目的maven坐标、依赖关系以及开发着需要遵循的规则、缺陷管理系统等。是一个项目级别的配置文件。
在此处也是我们添加依赖包的位置。
2、setting文件：
settings文件，一般存在与两个位置：
1.安装的地方：${M2_HOME}/conf/settings.xml
2.用户的目录：${user.home}/.m2/settings.xml
${M2_HOME}/conf/目录下的settings文件被叫做全局配置，对操作系统的所有使用者生效；
${user.home}/.m2目录下的被称为用户配置，只对当前操作系统的使用者生效。
如果两者都存在，它们的内容将被合并，并且用户范围的settings.xml会覆盖全局的settings.xml。
Maven安装后，用户目录下不会自动生成settings.xml，只有全局配置文件。如果需要创建用户范围的settings.xml，可以将安装路径下的settings复制到目录${user.home}/.m2/
Maven默认的settings.xml是一个包含了注释和例子的模板，可以快速的修改它来达到你的要求。
同时，settings文件还有一个重要的功能，配置仓库的位置。
在此处来进行本地仓库的配置。
Maven构件
Maven中的任何输出都可成为构件。
每个构件都有自己的唯一标识，有三个部分：groupId、artifactId和version等信息构成。
Maven的一个重要功能就是对这些构件进行版本控制和管理。
Maven构件标志
每个构件都有自己的唯一标识（Maven 行话称之为"唯一坐标"），由 groupId，artifactId 和 version 等信息构成。
-
groupId：当前Maven构件隶属的组织名。groupId一般分为多段，通常情况下，第一段为域，第二段为公司名称。域又分为 org、com、cn 等，其中 org 为非营利组织，com 为商业组织，cn 表示中国。以 apache 开源社区的 tomcat 项目为例，这个项目的 groupId 是 org.apache，它的域是org（因为tomcat是非营利项目），公司名称是apache，artifactId是tomcat。(必须)
-
artifactId：项目的唯一的标识符，实际对应项目的名称，就是项目根目录的名称。(必须)
-
version：当前版本。(必须)
-
packaging：打包方式，比如 jar，war... (必须)
-
classifier：classifier通常用于区分从同一POM构建的具有不同内容的构件。它是可选的，它可以是任意的字符串，附加在版本号之后。
classifier在一个POM项目的字段中不同的位置会出现不同的情况，要注意区分。
Maven构件的特性
1、项目依赖依旧传递性：项目依赖A，而A有依赖B，此时由于依赖性，项目A与B都会视作项目的依赖。
2、Maven依赖版本冲突的图例原则：构件之间存在版本冲突时，使用“最短依赖”原则加载构件。同时也可以在 pom.xml 中，使用 <exclusions></exclusions>显式排除某个版本的依赖，以确保项目能够运行。
3、项目的依赖范围：是Maven在构件项目的过程中会编译3套ClassPath，分别对应编译器、运行期和测试期，依赖范围的指定可以说明其作用于哪套ClassPath
关键词依赖范围见下图：
| 关键词 | 编译期 | 测试期 | 运行期 | 说明 |
| compile | √ | √ | √ | 默认范围 |
| provided | √ | √ | 如 servlet-api.jar，运行期由web容器提供。 | |
| runtime | √ | √ | 编译期无需直接引用。 | |
| test | √ | 如junit.jar。 | ||
| system | √ | √ | 必须通过 <systemPath></systemPath> 元素，显示指定依赖文件的路径， 与本地系统相关联，可移植性差。 | |
| import | 表示继承父POM.XML中的依赖范围设置 |
<dependencies>
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
<dependencies>
这里的scope指定了范围。
Maven的依赖冲突
Maven当中依赖分为直接依赖和间接依赖。
直接依赖还比较清晰，但是在间接依赖中就很有可能会出现依赖冲突的情况。
这里的依赖冲突通常指的是多方引入的过程中，出现了相同坐标不同版本的情况出现。
1、直接依赖冲突示例：
依赖冲突的原则：对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version。
<dependencies>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.3.0</version>
</dependency>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.5.0</version>
</dependency>
</dependencies>在这种情况下，同一个goupId和artifactId下出现了两个版本，由于代码编译器执行的问题，就会优先导入第一个声明的依赖，可能就会出现由于版本出现的问题。
依赖冲突的调节原则：路径优先原则、第一声明优先原则、排除原则和版本锁定原则。
Maven插件
插件也是Maven的另外一个重要部分。
可以理解为Maven本质上也是一个插件框架。它的核心并不执行任何具体的构件任务，将这些任务都交给插件来进行处理。
如图：
插件主要来完成以下任务：
1、创建jar文件
2、创建war文件
3、创建编译代码文件
4、代码单元测试
5、创建工程文档
6、创建工程报告
插件的运行集成在生命周期上，在每个生命周期都会有不同的插件运行。
Maven的生命周期
Maven有以下3个标准的生命周期（这里的生命周期指的是项目的部署到下线过程）：
1、clean：项目清理。主要用于清理上一次构件产生的文件，可以理解为删除target目录。
2、default/build：项目构建，一个项目的构架主要包含以下阶段：
-
-
process-resoures: 默认处理src/main/resource/下的文件，将其输出到测试的classpath目录中
-
compile：编译src/main/java下的java文件，产生对应的class
-
process-test-resoures: 默认处理src/test/resource/下的文件，将其输出到测试的classpath目录中
-
test-compile：编译src/main/java下的java文件，产生对应的class
-
test：运行测试用例
-
package：打包构建，生成对应的jar、war等
-
install：将构件部署到本地仓库
-
deploy：部署构件到远程仓库
-
3、site：站点文档创建。
每个生命周期中都包含着一系列的阶段(Phase)，这些phase就相当于Maven提供的统一的接口，这些phase的实现由Maven的插件来完成。
Maven生命周期和插件的绑定
生命周期本身只是一个抽象的概念，其本身没有执行任何的任务。
通过插件和生命周期的结合来实现一个编译的全过程。
通过生命周期的阶段(phase)与插件的目标goal相互绑定，用以实现实际的构件任务。每个插件本身代表了一个实现的目标，通过每个生命周期的阶段和目标的绑定，实现了Maven编译软件的过程。
插件和生命周期的绑定示例：
$ mvn compiler:compile
冒号前部分是插件前缀，后面部分是该插件目标，即: maven-compiler-plugin 的 compile目标。该目标绑定了 default 生命周期的 compile 阶段，从而能够实现项目编译的目的。
通过Maven命令调用Maven插件：
调用Maven插件的某个功能需要执行Maven命令来执行：
mvn [plugin-name]:[plugin-name]
其含义是：执行plugin-name的plugin-name目标，这个目标就是生命周期
用户可以通过两种方式调用Maven插件的目标：
1、将插件目标与生命周期阶段绑定(lifecycle phrase) 绑定，后在命令行中输入生命周期阶段即可。
2、直接在命令行输入指定要执行的插件目标，如上代码块。
_____________________________________________________________________________
待续......
178
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
