6月份多模块的gradle项目还扫描成功了
8月份公司sonarqube系统从6.4升级到了7.1
9月份构建多模块的gradle项目报错,报错信息如下:
由于我们项目依赖关系大概如下:
modules1
modules2
modules2:modules2.1
modules2:modules2.2
modules2:modules2.3
然后报错信息里面报错的目录是modules2:modules2.1的代码目录,后来试了下modules2下的模块都会报这个错
由于公司这种依赖关系的项目有好几个,然后查看了其他项目,发现有三个项目有这个问题,另外两个没有,询问了对应的开发人员,发现报错的三个项目,他们的模块依赖关系是在settings.gradle设定的,不报错的两个项目依赖关系是在app/jni/AndroidPrebuild.mk设定,由于对gradle的几个配置文件关联关系不太懂,于是去查找了下以前一位宝藏男孩留下的gradle的资料,了解如下:
一个新建的Android Stuido项目结构如下:
包含三个.gradle文件:
1、settings.gradle 文件对应脚本执行时的setting对象,该文件最先被解析和执行,一些通用的初始化操作可以放在这里执行,项目包含多个子工程或者模块时,必须在该文件中`include`,这也是其最重要的功能之一。新建项目默认的`settings.gradle`。
2、项目根目录下的`build.gradle`,对应脚本执行时的rootProject对象,一般不做具体的模块构建操作,用于指定项目所依赖的远程仓库和使用的Gradle plugin 插件版本,适用与所有的子工程或者模块
3、每个子项目或模块下单独的`build.gradle`脚本文件,在这里指定各自依赖的SDK,库属性等等,这也是我们编译的脚本的主体。指定的SDK、bulidtools版本,包名,应用版本号等等,注意这里面定义的属性会覆盖`AndroidMainfest.xml`文件中定义的。
先看一个简单的执行流程图:
- 创建Gradle对象,在执行任何一条gradle命令时,都会先创建一个全局唯一的Gradle对象,该对象可以保存一些全局的基本的值。
- 创建Setting对象,Gradle每次构建都会创建一个Setting对象,如果存在settings.gradle文件则会去解析该文件配置Setting对象。一个setting.gradle文件对应一个Setting对象,当项目依赖编译多个项目时,就需要在settings.gradle中include需要编译的与依赖的项目。后面看DSL文档会Setting对象持有一个rootProject对象,注意该对象的类型为`ProjectDescriptor`,而不是Project。
- 创建Project对象,在配置完Setinng对象后,开始创建Project对象,默认的创建的顺序:先创建rootProject 对象(注意这里的类型为Project),子模块的对象的创建依照settings.gradle文件中include的顺序进行。
- 解析上一步创建对象对应的build.gradle文件,按序添加task执行顺序,在解析完所有的Project对象后,最终会生成一个有向无环图表示所有需要执行task的执行顺序,注意解析文件是在其对应的Project对象后进行,而不是所有的Project对象创建后再进行。
- 依据上一步生成的有向无环图,执行脚本。
大致了解了下gradle几个文件的关系之后,选择先找出报错源头,到底是开发改东西导致的还是sonar升级导致的,于是将开发代码回退到6月份能正常扫码的时候,再跑一遍,还是报上面那个错,至此可以确定是升级sonarqube导致此问题,不知道sonarqube从6版本到7版本有了什么大变动,由于它的资料都是英文偏多,所以没去细究,以解决问题为主
这个问题困扰了好久,之前本来想着是把依赖关系给配置到sonar里面去,到时在网上找了好多资料配置都没用,后面看到这个答主的答案:https://blog.csdn.net/weixin_34370347/article/details/91911140
他的多模块配置我是没生效,但是看到了他的不分析某模块的配置,然后试了下发现可以使用
由于我们app中引用的项目是属于另外一个代码库的,按理说不应该在在此项目中扫描上传结果,所以使用了屏蔽方法,然后算是解决了问题把
遗留的困惑:
1、sonarqube从6.4到7.1到底变动了什么导致扫描失败
2、含有依赖关系的多模块gradle配置sonarqube的时候,到底要如何配置才会生效