maven学习
1、maven最开始
1.自己建三个在同一路径下的项目（不需要骨架）
2.由于自己导jar包，idea会从中央仓库到外网下载，速度慢，所以配置一些东西
-
找到apache-maven-3.5.0—conf—settings.xml
-
55行<localRepository>指定本地仓库的路径</localRepository>（idea中可以改，配置文件里删了也可以）
-
通过ali镜像下载，settings.xml里添加如下代码
<mirror>
<id>alimaven</id>
<mirrorOf>central</mirrorOf>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
<mirror>
<id>repo2</id>
<mirrorOf>central</mirrorOf>
<name>repo2 maven</name>
<url>http://repo2.maven.org/maven2</url>
</mirror>
<mirror>
<id>uk</id>
<mirrorOf>central</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://uk.maven.org/maven2</url>
</mirror>
<mirror>
<id>nexus</id>
<mirrorOf>central</mirrorOf>
<name>internal nexus repository</name>
<url>http://repo.maven.apache.org/maven2</url>
</mirror>
</mirrors>
1.
2.
3.
4.
注：我们可以到
5.
提问，为什么用1.2.14不用17呢？
自动剔除有两种思想：
-
最短路径优先（HelloFriend依赖Hello，MakeFriend依赖HelloFriend）
-
路径相同时先声明者优先（HelloFriend依赖Hello，MakeFriend依赖Hello，dependency先声明谁就依赖谁）
针对上图，maven自动处理用的是最短路径优先，后边的自动剔除了
maven找依赖的顺序：
-
根据gav(坐标)在本地仓库中查找
-
根据gav在远程服务器中下载，下载在本地仓库
-
如果都没有就是你乱输的
现在以crm为例 用maven构造 模块之间相分离：
依赖关系：
controller 依赖 service
service 依赖 mapper
mapper 依赖 bean
以上都可能依赖 utils，所以
bean 依赖 utils 所以（每个模块能分开开发! 因为高内聚低耦合）
2、构建环节
①清理：删除以前的编译结果，为重新编译做好准备。
②编译：将Java源程序编译为字节码文件。
③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
④报告：在每一次测试后以标准的格式记录和展示测试结果。
⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。
⑥安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库中。
⑦部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。
3、Maven核心概念
Maven之所以能够实现自动化的构建，和它的设计是紧密相关的。我们对Maven的学习就围绕它的九个核心概念展开：
①POM
②约定的目录结构
③坐标
④依赖管理
⑤仓库管理
⑥生命周期
⑦插件和目标
⑧继承 父工程(又可以作为聚合工程) 1.统一管理子工程jar的版本2.可以一键安装所有子工程
⑨聚合
4、POM
Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。
5、 约定的目录结构
现在JavaEE开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而Maven正是因为指定了特定文件保存的目录才能够对我们的Java工程进行自动化构建。
目录结构含义参见前面的描述。
6、 坐标
[1]在一个平面中使用x、y两个向量可以唯一的确定平面中的一个点。
[2]在空间中使用x、y、z三个向量可以唯一的确定空间中的一个点。
6.1、Maven的坐标
使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。
[1]groupId：公司或组织的域名倒序+当前项目名称
[2]artifactId：当前项目的模块名称
[3]version：当前模块的版本
<groupId>com.galaxy.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
6.2、如何通过坐标到仓库中查找jar包
[1]将gav三个向量连起来
com.galaxy.maven+Hello+0.0.1-SNAPSHOT
[2]以连起来的字符串作为目录结构到仓库中查找
com/galaxy/maven/Hello/0.0.1-SNAPSHOT/Hello**-**0.0.1-SNAPSHOT.jar
※注意：我们自己的Maven工程必须执行安装操作才会进入仓库。安装的命令是：mvn install
7、关键：对Hello的依赖
这里Hello就是我们的第一个Maven工程，现在HelloFriend对它有依赖。那么这个依赖能否成功呢？更进一步的问题是：HelloFriend工程会到哪里去找Hello呢？
答案是：本地仓库。任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行。
依赖管理
1.基本概念
当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。例如：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar。
通过第二个Maven工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的jar包。
配置的基本形式是使用dependency标签指定目标jar包的坐标。
例：commons-fileupload-1.3.jar导入到本地仓库，commons-io-2.0.1.jar会自动导入
2.直接依赖和间接依赖
如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。
3.依赖的范围
当一个Maven工程添加了对某个jar包的依赖后，这个被依赖的jar包可以对应下面几个可选的范围：
①compile默认的
[1]main目录下的Java代码可以访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖，在其他地方不能用 如：
[3]部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。
②test
[1]main目录下的Java代码不能访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：对junit的依赖。仅仅是测试程序部分需要。
③provided
[1]main目录下的Java代码可以访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。
④runtime[了解]
[1]main目录下的Java代码不能访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时会放在WEB-INF的lib目录下
例如：JDBC驱动。只有在测试运行和在服务器运行的时候才决定使用什么样的数据库连接。
⑤其他：import、system等。
使用场景：
依赖的传递性
当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如：
| Maven工程 | 依赖范围 | 对A的可见性 |
|---|---|---|
| A B C | compile | √ |
| D | test | × |
| E | provided | × |
依赖的排除
maven点击Show Dependencies...，选择需要排除的依赖右击Exclude刷新即可
统一管理目标jar包的版本
以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-core、spring-context等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同时使用4.1.1的spring-context。
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
问题是如果我们想要将这些jar包的版本统一升级为4.1.1，是不是要手动一个个修改呢？显然，我们有统一配置的方式：
<properties>
<spring.version>4.1.1.RELEASE</spring.version>
</properties>
……
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>