记录本周遇到的头疼了很久的一个问题，由于公司需要使用jenkins来自动管理构建项目，然后在关联sonar对项目代码质量进行审核。

接着坑爹的问题来了，原有的技术手段为项目构建成功后通过jenkins的构建后操作去触发提前配置好的sonar服务器对代码质量进行管理，然而处于技术层面以及每次项目构建时间上的考虑，现在需要对原有技术进行替换更新，决定使用在构建中去触发sonar。具体build执行命令如下：

　　clean cobertura:cobertura -Dcobertura.report.format=xml  -Dmaven.test.skip=false -Dmaven.test.failure.ignore=true org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar  -X

　　目前我们使用的jenkins服务器为远程服务器，同样sonar也为远程服务器。前提（项目本地单元测试没有问题，构建没有问题）。

　　在实际jenkins构建中出现以下问题：

　　1. 找不到相关依赖的问题。

　　　　此问题出的有一些莫名其妙，总体而言为根据maven配置在我们的本地仓库其实是存在相关依赖的，而且maven的setting文件中也配置了本地仓库地址。

　　　　具体解决方式就更奇葩：为将相关依赖关系在本地仓库移除，并根据包结构重新配置一遍就可以了。

　　2.找不到相关工程项目

　　　　我们的项目为多模块项目，在构建的时候根据输出日志可以查看到相关的每个模块的构建均为success，然而在最终整体项目构建的时候报错，根据记录日志提示为找不到相关工程项目。然后我们在到日志地址查看发现项目其实也是存在的。

　　具体解决方式：这个问题我们尝试过很多方式，包括更改包结构，统一Git仓库源码地址，单独整合单一模块测试。。等等。。然而均已失败告终。。最后根据build指令去推敲发现是因为build指令并不支持当前配置的soanr版本。。。。所以。。经过利弊权衡，最终我们选择了更换sonar服务器的版本。

最后说一下我们为什么会选择更改sonar版本，而非更改build命令。

　　因为我们整个工程下面涉及到19个模块服务，在未做出调整之前我们构建整个项目，并得到最终扫描结果所需要花费的时间大概是4个小时以上。也就是说如果在代码中存在必须要更改的质量问题，改一次然后在测试的成本太高。而通过后面一种方式构建到处sonar结果所需要的时间仅仅10多分钟，可以大幅提升效率。所以还是推荐使用后者。