maven的概念-02
1.仓库
仓库分为两类：
1） 本地仓库 ->当前电脑上的maven仓库；
本地仓库的默认目录：
${user.home}/.m2/repository
如果想修改本地仓库目录：
打开 maven解压目录/conf下的setting.xml;
找到<localRepository>标签；解开注释；写入仓库目录；
<localRepository>D:\maven\repository</localRepository>
2） 远程仓库 ->局域网私服；
->中央仓库和为其分担压力的镜像；
添加远程仓库：
打开 maven解压目录/conf下的setting.xml;
找到<mirrors>标签；向里面添加一条<mirror>;
<mirror>
<id>nexus-public-snapshots</id>
<mirrorOf>public-snapshots</mirrorOf>
</mirror>
3）仓库中的文件：
maven插件；
自己开发的项目模块；
第三方jar包；
不管是什么样的jar包，都是按照坐标来建立目录结构的；所以可以通过统一的方式来查询或依赖；
2.依赖
依赖是maven中的关键部分，我们使用maven最主要就是使用它的依赖管理功能；
1）关于依赖
当A jar包用到了B jar包中的某些类时，A就对B产生了依赖；
在java工程中添加依赖的方式为：在pom.xml 文件的 <dependencys>标签下 ，添加一条<dependency>
例如：添加junit依赖：
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<!-- 表示开发的时候引入，发布的时候不会加载此包 -->
<scope>test</scope>
</dependency>
依赖的格式是按目标jar包的坐标来的；
其中的<scope>标签里的内容表示依赖的范围；
2）关于依赖的范围
常用的依赖范围有三个：
compile ->对主程序和测试程序可见；也会参与项目的部署；最主要的依赖范围；
test ->只对测试程序可见，不参与部署；
也就是说，maven标准目录结构中的src/main/java里的程序不可以使用用该jar包里的内容；
只有src/test/java里的程序可以依赖test范围的jar包；
项目部署到服务器上时，test范围的jar包不会被部署；
例如junit;
provided ->对主程序和测试程序可见；不参与部署；例如；servelet-api；服务器中自带，不需要部署，但测试程序和主程序还必须依赖；
依赖有效性如图：
3）依赖的传递性：
如果A依赖B;
B依赖C;
A是否能使用C取决于B依赖C的范围是否是compile;
4）依赖的排除
如果当某个java工程依赖jar包A;
而 A依赖 B;
maven 将自动引入B;
这样会有一个问题：如果B不稳定，不想让B被自动引入；
可以在依赖A 时排除B;
配置方式：用<exclusions>标签
<dependency>
<groupId>com.liusir</groupId>
<artifactId>hello</artifactId>
<version>1.0</version>
<scope>compile</scop>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
5）统一化管理依赖jar包版本
对于同一个 框架的一组jar包，最好使用相同的版本；
为了方便升级框架，可以将jar包的版本信息统一提取出来；
具体操作：
1】 统一声明版本号：com.liusir.version是自定义标签
<properties>
<com.liusir.version>4.02<com.liusir.version>
</properties>
2】引用前面声明的版本号
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${com.liusir.version}</version>
</dependency>
3】其它用法
比如声明字符集；当然引用时和版本号的引用方式一样；
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
6）依赖的原则
路径最短者优先：
比如说，MakeFriend依赖HelloFriend;
HelloFriend依赖Hello;
HelloFriend和Hello中都依赖了log4j，由于依赖传递两个log4j都会传递到MakeFriend;
根据路径最短者优先，MakeFriend 会依赖 HelloFriend中的 log4j;
路径相同时先声明者优先；声明先后顺序是指dependency标签配置的先后顺序；
比如说，MakeFriend同时依赖HelloFriend 以及 OurFriend;
HelloFriend和OurFriends中都依赖log4j ；
而HelloFriend 对两个类的 依赖路径都是 1；
根据先声明者优先的原则，如果HelloFriend在MakeFriend的pom.xml中dependency先配置，MakeFriend就依赖HelloFriend的log4j ；
3.maven的生命周期
maven的生命周期定义了各个构建环节执行的顺序；
有了这个清单maven就可以自动化执行构建命令了；
maven有三个独立的生命周期：
clean lifecycle ->进行构建之前的一些清理工作；
default lifecycle ->构建的核心部分；编译、测试、打包、安装、部署等；
site lifecycle ->生成项目报告、站点、发布站点；
三个周期之间是相互独立的；
例如 ：mvn clean 仅能用来清理；mvn site 用来生成站点；也可以 mvn clean install site 同时运行三套生命周期；
每套生命周期都由一组阶段组成；
平时输入命令时总对应于一个特定的阶段；
例如：mvn clean 对应clean周期里的clean阶段；clean周期里还有其它阶段；
1）clean周期
clean周期包含三个阶段：
①pre-clean 执行一些需要在clean之前完成的工作
②clean 移除所有上一次构建生成的文件
③post-clean 执行一些需要在clean之后立刻完成的工作
2）site 周期
①pre-site 执行一些需要在生成站点文档之前完成的工作
②site 生成项目的站点文档
③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
④site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动 生成，很好看。
3）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。
pre-integration-test
integration-test
post-integration-test
verify
install将包安装至本地仓库，以让其它项目依赖。
deploy将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。
4）生命周期与自动化构建
运行任何一个阶段时，它前面的所有阶段都会被执行；
例如：mvn package打包命名，不仅会打包，还会执行前面的 编译mvn compile、测试mvn test等；
这也是maven能自动执行构建过程的原因；
maven的插件机制是完全依赖maven的生命周期的；
4.插件和目标
maven 的核心仅定义了抽象的生命周期，具体任务都是插件完成的；
每个插件都能实现多个功能，每个功能就是一个插件目标；
maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务；
例如：compile 是插件 maven-compiler-plugin 的一个目标；
test-compile 也是插件 maven-compiler-plugin 的一个目标；
pre-clean 是插件 maven-clean-plugin的一个目标；
eclipse中的maven插件：
eclipse中一般集成了maven插件；windows|preferences|maven 可找到maven设置；
其中重要的配置有：installtions和user settings
选 installtions 可设置maven 的位置；
user settings 指定 conf/settings.xml的位置，进而通过配置来获取本地仓库位置；
5.继承
因为依赖的传递规则中，只有compile范围的依赖可以传递；
有时候为了统一管理版本，其它范围的依赖也需要统一；比如junit经常是test范围；
这是可以利用继承机制；
例如：将junit依赖统一提取到父工程；在子工程中声明junit依赖时不指定版本，以父工程为主；
①创建Parent工程，打包方式为pom
②收集所有非compile范围的依赖信息，使用dependencyManagement标签统一管理
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
③在各个子工程中引用父工程
<parent>
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 以当前文件为基准查找父工程中pom.xml文件的相对路径 -->
<relativePath>../Parent/pom.xml</relativePath>
</parent>
④删除子工程中的重复信息
groupId
artifactid
⑤在子工程中找到被父工程管理的依赖信息，删除版本号部分
⑥在父工程中统一修改已管理的依赖信息的版本号，看是否能够控制所有子工程
6.聚合
配置继承后，要先安装父工程；否则子工程就没法安装；
如果要将父工程和其所有的子工程一起安装；可以利用聚合；
聚合的作用是一起安装；
配置：在总的聚合工程中加入如下信息
例如：Hello、HelloFriend、MakeFriends都是Parent的子模块；
可在 Parent工程的pom.xml中添加聚合配置；
<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>
输入：mvn install 安装Parent时，其子工程也会一起安装；
注意:聚合和继承没有必然的联系；
7.自动化部署（不常用）
8.网址
我们可以到http://mvnrepository.com/搜索需要的jar包的依赖信息。
