送大家以下java学习材料，文末有支付形式
当初的我的项目中 Maven 随处可见，面试的时候，常常会被问一些我的项目中 Maven 的问题，然而平时 Maven 我的项目个别不会出什么问题，可能你不太留神，以下7个问题，个别说进去并把握，至多能够证实你 Maven 用的熟练度还能够。
Maven的仓库治理、依赖治理、继承和聚合等个性为我的项目的构建提供了一整套欠缺的解决方案，如果你搞不懂Maven，那么一个多模块的我的项目足以让你头疼，依赖抵触就会让你手足无措，甚至搞不清楚我的项目是如何运行起来的...
OK，博主就已经被Maven“挫伤”过，所以，咱们要：彻底搞定Maven！
回忆一下，当你新到一家公司，装置完JDK后就会装置配置Maven，很大可能性你须要批改settings.xml文件，比方你会批改本地仓库地址门路，比方你很可能会copy一段配置到你的settings.xml中（很可能就是私服的一些配置）。接下来，你会到IDEA或者Eclipse中进行Maven插件配置，而后你就能够在工程中的pom.xml外面开始增加标签来治理jar包，在Maven标准的目录构造下进行编写代码，最初你会通过插件的形式来进行测试、打包（jar or war）、部署、运行。
下面形容了对Maven的一些应用形式，上面咱们进行一些思考：
1、本地仓库？Maven到底有哪些仓库？它们什么关系？
Maven仓库：
本地仓库门路配置：
你要jar包，不可能每次都要联网去下载吧，多吃力，所以本地仓库就是相当于加了一层jar包缓存，先到这里来查。如果这里查不到，那么就去私服上找，如果私服也找不到，那么去地方仓库去找，找到jar后，会把jar的信息同步到私服和本地仓库中。
私服，就是公司外部局域网的一台服务器而已，你想一下，当你的工程Project-A依赖他人的Project-B的接口，怎么做呢？没有Maven的时候，当然是copy Project-B jar到你的本地lib中引入，那么Maven的形式，很显然须要其他人把Project-B deploy到私服仓库中供你应用。因而私服中存储了本公司的外部专用的jar！不仅如此，私服还充当了地方仓库的镜像，说白了就是一个代理！
地方仓库：该仓库存储了互联网上的jar，由Maven团队来保护，地址是：http://repo1.maven.org/maven2/。
2、对于<dependency>的应用
依赖治理：
img\_0822\_02\_\_4.png
其实这个标签揭示了jar的查找坐标：groupId、artifactId、version。
一般而言，咱们能够到私服上输出artifactId进行搜寻，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。
version分为开发版本（Snapshot）和公布版本（Release），那么为什么要分呢？
在理论开发中，咱们常常遇到这样的场景，比方A服务依赖于B服务，A和B同时开发，B在开发中发现了BUG，批改后，将版本由1.0降级为2.0，那么A必须也跟着在POM.XML中进行版本升级。过了几天后，B又发现了问题，进行批改后降级版本公布，而后告诉A进行降级...能够说这是开发过程中的版本不稳固导致了这样的问题。
Maven，曾经替咱们想好了解决方案，就是应用Snapshot版本，在开发过程中B公布的版本标记为Snapshot版本，A进行依赖的时候抉择Snapshot版本，那么每次B公布的话，会在私服仓库中，造成带有工夫戳的Snapshot版本，而A构建的时候会主动下载B最新工夫戳的Snapshot版本！
3、既然Maven进行了依赖治理，为什么还会呈现依赖抵触？解决依赖抵触的伎俩是？
依赖的版本？
首先来说，对于Maven而言，同一个groupId同一个artifactId下，只能应用一个version！
依据上图的依赖程序，将应用1.2版本的jar。
当初，咱们能够思考下了，比方工程中须要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C，那么问题来了，C应用的版本将由引入A、B的程序而定？这显然不靠谱！如果A的依赖写在B的依赖前面，将意味着最初引入的是1.0版本的C，很可能在运行阶段呈现类（ClassNotFoundException）、办法（NoSuchMethodError）找不到的谬误（因为B应用的是高版本的C）！
这里其实波及到了2个概念：依赖传递（transitive）、Maven的最近依赖策略。
依赖传递：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。
Maven的最近依赖策略：如果一个我的项目依赖雷同的groupId、artifactId的多个版本，那么在依赖树（mvn dependency:tree）中离我的项目最近的那个版本将会被应用。（从这里能够看出Maven是不是有点小问题呢？能不能抉择高版本的进行依赖么？据理解，Gradle就是version+策略）
当初，咱们能够想想如何解决依赖抵触呢？
想法1：要应用哪个版本，咱们是分明的，那么能不能不论如何依赖传递，都能够进行版本锁定呢？
应用<dependencyManagement> 这种次要用于子模块的版本一致性中
想法2：在依赖传递中，能不能去掉咱们不想依赖的？
应用<exclusions>在理论中咱们能够在IDEA中间接利用插件帮忙咱们生成
想法3：既然是最近依赖策略，那么咱们就间接应用显式依赖指定版本，那不就是最靠近我的项目的么？
应用<dependency>
4、引入依赖的最佳实际，提前发现问题！
在工程中，咱们防止不了须要加一些依赖，兴许加了依赖后运行时才发现存在依赖抵触在去解决，仿佛有点晚！那么能不能提前发现问题呢？
如果咱们新退出一个依赖的话，那么先通过mvn dependency:tree命令造成依赖树，看看咱们新退出的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在抵触，如果存在多个版本抵触，利用上文的形式进行解决！
5、Maven规范化目录构造
这里须要留神2点：
1、src/main下内容最终会打包到Jar/War中，而src/test下是测试内容，并不会打包进去。
2、src/main/resources中的资源文件会COPY至目标目录，这是Maven的默认生命周期中的一个规定动作。（想一想，hibernate/mybatis的映射XML须要放入resources下，而不能在放在其余中央了）
6、Maven的生命周期
Maven生命周期：
咱们只须要留神一点：执行前面的命令时，后面的命令主动失去执行。
实际上，咱们最罕用的就是这么几个：
1、clean：有问题，多清理！
2、package：打成Jar or War包，会主动进行clean+compile
3、install：将本地工程Jar上传到本地仓库
4、deploy：上传到私服
7、对于scope依赖范畴
既然，Maven的生命周期存在编译、测试、运行这些过程，那么显然有些依赖只用于测试，比方junit；有些依赖编译用不到，只有运行的时候能力用到，比方mysql的驱动包在编译期就用不到（编译期用的是JDBC接口），而是在运行时用到的；还有些依赖，编译期要用到，而运行期不须要提供，因为有些容器曾经提供了，比方servlet-api在tomcat中曾经提供了，咱们只须要的是编译期提供而已。
总结来说：
1、compile：默认的scope，运行期无效，须要打入包中。
2、provided：编译期无效，运行期不须要提供，不会打入包中。
3、runtime：编译不须要，在运行期无效，须要导入包中。（接口与实现拆散）
4、test：测试须要，不会打入包中。
5、system：非本地仓库引入、存在零碎的某个门路下的jar。（个别不应用）