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, 當然這個風險可能會有，小心行事。
以上，就是一點點問題排查心得，聊以慰藉。也希望對有類似的問題的同學指明一個方向。
遇到問題的時候我們往往是這樣，一個問題，可能幾天下來也不一定能解決，但是到真正解決了的時候，發現其實很簡單。然后，也許下一次，又繼續！