最近maven遇到的问题

最近一段时间，项目要做一些升级，首先weblogic要从11g升到12c，除了安装新的weblogic之外，还要更新jdk的版本，从1.6更新到1.8。然后是依赖framework的版本，因为之前一直没有更新，所以要从9.x.x升到12.x.x。将toplink换成eclipselink。最后maven的依赖仓库也有变化，从上海的artifactory到hk的。下面就是我做这些改动遇到的问题

1.没有清空本地仓库

在更新完一些基本配置后重新import依赖发现新的仓库缺失的jar并不多，然而这只是一个假象。在本地的repository中还有从原来artifactory下载下来的jar包，而maven在本地package的时候先找本地仓库，所以即使远程仓库仲有很多jar没有，在本地还是可以通过的。所以在更换远程仓库的时候一定要注意，先清空本地的repository。另外还有一点就是setting.xml的设置，远程仓库的地址就是在这里更新，值得注意的是要将其他的repository设置成enable为FALSE。

2.导入本地依赖

因为换了新的artifactory，所以很多依赖在新的仓库中都没有。并且还有就是要上传新的jar到新的仓库需要提供很多信息，并且要经过审核（起码两天）才能用，而经过排查，项目有几十个jar是新的仓库没有的，所以这是一个大工程。另外还有一点就是要去看每个依赖的licence，当然这是必须的，但是这也是短时无法解决的事情。所以我决定先把需要的jar放在项目中，引用项目中的依赖先在测试环境上测试，再进行之后的工作。

醉出我的想法是两步走。第一步将jar包放在本地的lib文件夹中，然后在pom中将相关的dependency设置成本地引用：

……

system

……

这里的system就是标明我要使用本地依赖。

因为这种方式在使用maven-dependency-plugin的copy-dependency的时候是不会拷贝的，所以我试图使用相同插件的copy的goal将本地依赖copy到要打包的jar文件夹下。

然而第二步这种方法并不奏效，因为在copy的时候，它并不知道我要copy的是本地的jar，所以第一时间是去repository中去找，但是它并找不到这个jar，所以无法完成copy。

于是我又想了另一个办法，因为之前的项目是通过编写ant脚本来实现很多文件搬运的工作的，而maven本身有maven-antrun-plugin插件，可以使用他的简单配置完成文件的搬运工作。

好像还有另外一种方式可以实现依赖本地的jar，需要配置一个本地的repository，在配置的目录下放置要依赖的jar包。但是值得注意的是，这里面要严格按照groupid/artifactid/version/….jar的目录来存放文件。

当然在这个部分我还犯了另一个错误，因为这种方式本地的jar是要push到项目的repository上面的，但是之前的项目并不需要，所以之前的gitignore中将jar类型文件忽略了，导致jar并没有上传上去。所以在build jenkins的时候报出在特定目录下找不到依赖jar的错误。

3.解决依赖冲突

更新后的项目依赖可能来自新的远程仓库，因为仓库是新的，有的版本的依赖没有，所以也会更新一些版本信息，然后没有的依赖要用本地的jar，资源来自不同地方，版本也有更新，所以就可能有依赖的冲突。

最开始我采取的方式是和过于已经能够成功deploy的ear 用beyoundcompare进行比较，一个是观察有没有缺失的jar，然后就是看有没有多出来的重复的不同版本的jar。一旦发现存在重复的jar，用maven的dependency：tree命令观察重复的依赖是如何产生的，之后将它exclude掉。但是当我做完这个工作之后，发现deploy的时候还是存在依赖冲突，所以发现这个做法很笨且无效，应该存在某种maven命令能够直接检测依赖冲突，果然这种命令式存在的，如下：

mvn -X compile dependency:tree -Dverbose >a.log

这样可以直接生成依赖树，并且会标记依赖冲突，通过search “omitted for conflict with”可以看到冲突的jar，然后将他们exclude就可以了。

还遇到一种情况很奇怪，就是exclude了冲突的jar之后发现编译不过了，明明依赖了更新版本的jar，于是我在打包的时候将它直接exclude掉了，在deploy的时候也没有出现问题。

虽然花了很长时间才成功jenkins build成功，但是还是收获了很多知识和处理问题的思路。以后再遇到类似的情况就能更好的应对了。