最近一段时间,项目要做一些升级,首先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设置成本地引用:
……
<scope>system</scope>
<systempath>……</systempath>
这里的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成功,但是还是收获了很多知识和处理问题的思路。以后再遇到类似的情况就能更好的应对了。