Maven的基本操作

Maven的基本操作

1.maven仓库

2.依赖标签的含义

	jar坐标：groupId -> artifactId -> version。

	version分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？
	
		问题：
		  A服务依赖于B服务，A和B同时开发，B在开发中发现了BUG，修改后，将版本由1.0升级为2.0，
		  那么A必须也跟着在POM.XML中进行版本升级。
		  过了几天后，B又发现了问题，进行修改后升级版本发布，然后通知A进行升级...
		  可以说这是开发过程中的版本不稳定导致了这样的问题。
		  
		Snapshot版本解决问题：  
		在开发过程中B发布的版本标志为Snapshot版本，A进行依赖的时候选择Snapshot版本，
		那么每次B发布的话，会在私服仓库中，形成带有时间戳的Snapshot版本，
		而A构建的时候会自动下载B最新时间戳的Snapshot版本！
		

3.既然Maven进行了依赖管理，为什么还会出现依赖冲突？处理依赖冲突的手段是？

	2个概念：依赖传递（transitive）、Maven的最近依赖策略。

	依赖传递     ：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。
	maven最近依赖：如下图所示
	
	注：Gradle就是version+策略，即高版本依赖 ； 而maven是最近依赖
	

​ 根据顺序最后使用的版本是1.2

	依赖冲突：
	  比如工程中需要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C。
	  C使用的版本将由引入A、B的顺序而定？这显然不靠谱！
	  如果A的依赖写在B的依赖后面，将意味着最后引入的是1.0版本的C，B因为高版本的C，可能报找不到类的错
	
	解决依赖冲突：
	  方式1：<dependencyManagement>主要用于子模块的版本一致性中
	  方式2：<exclusions>在依赖传递中去掉不想依赖的
	  方式3：<dependency>直接显示依赖版本
	  

4.查看maven版本依赖树是否版本冲突

生成依赖树并输出到当前项目的"tree.txt"

5.maven规范化目录结构及打包方式

	src/main下内容最终会打包到Jar/War中，而src/test下是测试内容，并不会打包进去。

6.maven的生命周期

	1、clean：清理文件夹"target"下的编译文件
	2.compile：将src/main下等=源码资源编译到文件夹"target"下
	3、package：打成Jar or War包放入文件夹"target"，会自动进行clean+compile 
	4、install：打成Jar or War包放入文件夹"target"，并将其上传到本地仓库
	5、deploy：上传到私服

执行后面的命令时，前面的命令自动得到执行

编译或者打包放置的位置

install后放入本地仓库

7.maven依赖的scope依赖范围

	小结：
	1、compile：默认的scope，运行期有效，需要打入包中。
	2、provided：编译期有效，运行期不需要提供，不会打入包中。
	3、runtime：编译不需要，在运行期有效，需要导入包中。（接口与实现分离）
	4、test：测试需要，不会打入包中。例：测试类
	5、system：非本地仓库引入、存在系统的某个路径下的jar。（一般不使用）