原文出处：等你归去来
maven是一个很好的项目管理工具，你可以轻松的定义一个引用，从而达到使用别人写好的库的作用。且maven可以轻松地和jenkins配合，从而使打包部署变得更容易。
但是也因为这样，我们变得更傻瓜了，以致于有时候都忘了一些原始的基础的方法了，当然这不是本文的目的，本文的目的在于，如何解决一些maven带来的冲突问题。
问题1： jenkins 打包失败了，导致我无法安装代码到测试环境，怎么办？
答： 一般我们都会基于jenkins做一些二次开发，以适应公司内部的需求，或者优化一些修改化的东西。 但是由于jenkins本身还是比较复杂的，有时候难免我们搞不清楚其原理，从而导致一些无法打包的问题。 当然，我这边遇到的问题一般都是由于jenkins的缓存机制导致的问题，所以，在我本地可以打包的代码，放到jenkins上就死活打不了包，因为我依赖的一个jar包，由于被jenkins缓存了一个老版本的包，里面没有我新的东西从而导致打包失败，看起来短时间内无法解决这个缓存问题。
于是，我通过本地ide工具打好war包后，上传到服务器的tomcat目录，等待tomcat自动部署完成后就可以重新启动新代码了，从而绕过了jenkins失败的问题了。
针对jar包，则更为方便，直接本地生成jar包，然后替换服务器上的相应包，重启服务即可。
总之，这里的解决方案就是，当工具出了问题的时候，我们就不能再依赖工具了，回到原始状态解决问题。
问题2： 当我们运行了代码（war/jar）后，报某个方法未找到，即：java.lang.NoSuchMethodError:， 仔细查看代码，其实是有该方法的，如何排查？
答： 针对该问题，一般情况下都是由于引入了多个相同功能的jar包，且包路径完全一致，而在类加载器加载时，可能会加载到你不想要加载的类，从而导致没有该方法。
解决办法就是，删除不是自己的引用，从而达到使用自己意图的类。maven中即表现为排除某个依赖，如：
<dependency>
<groupId>com.xx.activity</groupId>
<artifactId>abc</artifactId>
<version>2.0.13-SNAPSHOT</version>
<classifier>dubbo</classifier>
<exclusions>
<exclusion>
<groupId>com.meidusa.venus</groupId>
<artifactId>venus-backend</artifactId>
</exclusion>
</exclusions>
</dependency>但是，还有个问题，那就是如何才能找到是引用了哪个包，才导致的冲突呢？因为你从本地代码来看，没有一点异常。
我们可以直接搜索整个包的引用，并解开其中的代码，查看是冲突的类（冲突方法比较难找出来），当然是直接在服务器上进行查找了。
find . -name '*.jar' -exec jar -tvf {} \; | grep EE # 即找出所有的jar包，再解压出其文件列表，再搜索冲突的类名如果有发现两个相同的结果，那么就是冲突了，解决该冲突即可。
当然，如果引入的jar文件不多，或者你有基本方向怀疑是哪个包冲突了，那么，直接将该包下载下来，用反编译工具（如jd-gui）编译出来，查看其内部情况，便一目了然。
问题3： 发现tomcat启动异常快，而且很多加载流程都没有，就直接启动了，实际上各个应有的服务都不存在，这怎么排查？
答： 这种问题比较没有头绪，解决起来也基本靠运气。 这里tomcat看起来正常启动了，但是实际上很多事情都没做，没加载。从另一个角度来说，就是加载中断了。最麻烦的是日志中一点信息都不会给出。一般可以先从代码的改动处开始排查，以一段一段的代码还原方式为主要排查手段。
其中有一很关键的问题就是，你引用了一个jdk版本比你自己的运行环境高的jar包，按照jvm的加载原理，其会先检查class文件的版本号，如果高于自己所能加载的版本，那么，它就直接拒绝加载了，而并不会检查该class文件是否引用了一些不认识的特性。如果jvm不加载类了，那么你后续流程就无法进行了。
如果确实是因为jar包版本导致的问题，那么，问题就好解决了。 1. 要么叫给你提供jar包的同学将其打包的jdk版本降到你需要的版本就可以了。 2. 升级自己的jvm运行环境，升级jdk, 当然这个风险可能会有，小心行事。
以上，就是一点点问题排查心得，聊以慰藉。也希望对有类似的问题的同学指明一个方向。
遇到问题的时候我们往往是这样，一个问题，可能几天下来也不一定能解决，但是到真正解决了的时候，发现其实很简单。然后，也许下一次，又继续！
