那今天这期视频我们将带来一个 IDEA 中 Maven 设置的小技巧。
那这个技巧可以说非常有用，学会设置之后，再也不用担心 maven 依赖下载变慢的问题。
那默认情况下， Maven 远程中央仓库地址为是个国外的地址。
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
不过还有一些异常情况不是那么直观，google一般搜不到有效的信息，就需要深入研究排查。新人遇到这类问题，往往一脸懵逼，不知如何下手，请教高手，高手如果只是简单指导一个方向，新人踩过几个坑没解决后会更加沮丧。甚至怀疑自己遇到一个神秘的无法解决的bug。有经验的开发往往也不能一眼就看出问题的修复方案，但是排查问题多了会有大概的思路，需要沉下心来不断的踩坑、爬坑，最终才能定位解决问题。
本文以Maven构建工具为例，从原理、思路、工具、实践几方面分享Java中复杂jar包依赖问题排查经验。
1、基础知识：Maven依赖传递策略
compile （编译范围）：默认策略；编译，测试，运行，打包都能用
provided （已提供范围）：编译，测试可用，不会打包到package包中。大部分情况下需要底层环境提供，比如tomcat服务中已经内置了servlet包，代码写代码时需要调用servlet的类
runtime （运行时范围）：只有运行时才可用，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现。
test （测试范围）：test范围依赖在编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。
system （系统范围）：system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径。适合maven中央仓库中不存在jar包引用。
2、基础知识：Maven依赖树的解析规则
深度优先遍历依赖，并缓存节点剪枝。比如下图：
在第二步A→C→D时，由于节点D已经被缓存，所以会立即返回，不必再次遍历E/F，避免重复搜索。
比如下图 A 通过 B 和 D 引入了 1.0 版本的 E，同时 A 通过 C 引入了 2.0 版本的 E。针对这种多个版本构建依赖时，Maven 采用短路径优先原则，即 A 会依赖 2.0 版本的 E。如果想引入 1.0 版本的 E，需要直接在 A 的 pom 中声明 E 的版本。
maven中禁止有循环依赖。比如A 依赖了 B，同时 B 又依赖了 A。这种循环依赖可能不会直接显现，但是会在一个很长的调用关系显现出来
（4）Maven多模块问题
B模块依赖A模块，A模块的依赖修改了，需要install一下，B模块才能感知到最新的依赖。
开发环境，建议默认日志级别设置为info，对需要关注的模块，建议设置为debug模式，比如当前工程目录，正在联调的依赖jar包。
如果异常无法定位，第一反应应该是添加日志。
添加以下有空的命令行参数：
安装插件后左下角会出现个新标签页，点击后搜所有此模块依赖的jar包及冲突情况
新项目碰到错误，复杂的问题，先不要深入研究，先看下是否有以下情况：
java的错误栈是从报错的最底层逐步往上打，这样能很方便的定位，一般的问题通过此手段定位问题后即可很快修复。
复杂点的异常，比如jar包冲突异常，最底层的异常一般都是基础组件，比如类加载器、日志组件等，这种情况就要多看几层。
大部分问题都是新引入依赖导致，从上往下查看变动，配合从下往上定位信息，定位出问题的组件。
背景：新需求接入舆情SDK，测试环境测试通过，线上发布有大量机器tomcat启动失败。
（2）尝试修复：第一次
机器上使用的是tomcat6, 还不支持java9的新模块策略，遂升级tomcat6到tomcat8，启动错误还有
（3）尝试修复：第二次
重新发布，又报了以下异常：
（4）尝试修复：第三次
报错Not running on Jetty，而我们的服务是运行在tomcat上，配合从上到下排查的思路，在新引入的maven依赖项打开pom.xml，查看里面的依赖项还有parent里的依赖项，找到了以下元凶：parent里会依赖***-boot-starter-web，而这里默认使用jetty作为引擎，遂排除掉，并验证业务逻辑是否正常。
2、新加依赖后服务启动失败
从堆栈初步看是以下包不兼容导致的：swift-codec或guava，还有mtthrift。刚开始重点排查了swift-codec或guava的兼容问题，将其降级和新引入jar包里的版本一致，启动错误还在
刚开始没往mtthrift方面想，因为mtthrift是美团的基础组件，一般情况下不会出现兼容的问题，查看官方wiki也没说有兼容问题
查看新引入的依赖，打开pom.xml，发现里面引入了MDP 1.5.5版本，而我们的项目的是最新的MDP 1.6.6.1, 初步判断是MDP包冲突，所以就把新包的MDP包排除掉
（4）排查版本不一致的依赖
到现在基本可以认为是mtthrift升级导致的不兼容问题。我们引入的jar包只需要其中了api定义，并不需要依赖的依赖，所以把所有的依赖都排除掉。重新引入和依赖包一致的mtthrift版本。重新启动，问题解决。
这个问题解决过程中走了很多弯路，一般我们的认为基础组件升级会兼容老版本，还有一点加深了这个认识：项目里引入的其他的thrift-client包，并没有出现问题。
但不幸的是，这个正好遇到了此类问题。从最终的解决方案看，应该是新引入的jar包编译的问题。
Maven包依赖问题是开发中的常见问题，如果不熟悉排查方案，会浪费大量时间。本文从工具、方法论、实践方面做了一些思考，希望对大家日常开发有帮助。
作者简介：美团Java高级工程师，关注软件架构及职业成长，不定期分享各种技术、资源，对文章中涉及的技术感兴趣或有任何问题请关注微信交流。
版权声明：本文为博主原创文章，遵循 版权协议，转载请附上原文出处链接和本声明。
1. 新建maven项目时候pom.xml文件报错？（如图）：
解决方法：1. 添加Tomcat依赖。
svn导入了一个maven项目，结果会出现获取不到远程仓库的依赖的问题：
setting文件中加入了ali的私服地址，然后通过maven clean、maven install、update project等，将项目的错误排掉，依赖如果还是报错，将本地仓库对应的文件夹删掉重新获取一下，
有的依赖，比如今天的Oraclejar包和那个ID什么什么xxclent那个，maven获取不到，需要手动去下载放进去。
在获取依赖时，忽然中断，也可以这么搞，删除掉最后一次更新
这个可能是导包的问题：
那一般是因为少了对应的javaxb类库导致，maven引入以下类包即可。
bash 给你一套源代码，你怎么能跑起来？
不能把！就是几个文件夹，几个文件。是不能运行的！
是不是需要和idea打交道，告诉idea怎么样才能运行起来，比如知道main方法在哪里？配置文件在哪里，编译好的文件输出到哪里，是不是？当然eclipse也一样。
平时我们是怎么构建项目的，项目怎么运行起来呢？
一切设置好以后，使用工具（idea）帮我们打包
项目构建中几个关键点?
2、哪些文件夹是干啥的！！ 源文件？配置文件？测试文件？在哪里？
（3）配置全局编译jdk版本
运行完毕，在浏览器访问
输入默认的用户名和密码admin/xxxxxxxx即可登录。
进入界面后顶部由2个按钮，分别是仓库和设置。可以看到由4个默认的仓库。
一般来说，Nexus 的仓库分为这么几类：
以下为了解，对私服进行权限认证（了解）
大部分公共的远程仓库无须认证就可以直接访问，但我们在平时的开发中往往会架设自己的Maven远程仓库，出于安全方面的考虑，我们需要提供认证信息才能访问这样的远程仓库。
配置认证信息和配置远程仓库不同，远程仓库可以直接在pom.xml中配置，但是认证信息必须配置在settings.xml文件中。
这是因为pom往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只存在于本机。因此，在settings.xml中配置认证信息更为安全。
Maven 实际上是一个依赖插件执行的框架，每个任务实际上是由插件完成。Maven 插件通常被用来：
插件通常提供了一个目标的集合，并且可以使用下面的语法执行：
添加插件在build中
点击idea右侧的maven我们可以方便的看到我们使用了什么插件，并可以点击执行相应的命令
通过插件和命令我们都可以启动项目了，都不用部署到tomcat里了。
我们日常使用的以maven-assembly-plugin为最多，因为大数据项目中往往有很多shell脚本、SQL脚本、.properties及.xml配置项等，采用assembly插件可以让输出的结构清晰而标准化。
自己网上查资料深入学习
插件太多了，基本上所有的功能都是通过插件附加的！
Archetype 是一个 Maven 插件，其任务是按照其模板来创建一个项目结构。
执行如下命令即可创建Maven项目模板。
一个最简单的Maven war项目模板，当需要快速创建一个Web应用的时候可以使用它。生成的项目内容包括：
