【gradle】Caused by: groovy.lang.MissingMethodException: No signature of method的解决方案和检查方法

【gradle】Caused by: groovy.lang.MissingMethodException: No signature of method的解决方案和检查方法

最近在编写gradle插件的时候报了这个错。找了一圈网上的方法也没有系统性的检查方法，因此记录一下我在解决这个报错时踩的坑。

出现这个报错最主要的问题肯定就是和这个method相关的脚本出现了方法调用或者环境配置上的问题。因此我们按照这个思路分别检查以下问题。

方法调用引发的报错

1. 方法调用时是否存在错误，最低级的错误就是调用的方法名和脚本编写的方法名对不上。按照这个思路顺序检查大小写、单词拼写问题即可。
2. 层级结构问题，搞错了脚本方法的层级结构，导致无法调用到对应的方法。
   一般遇到这类问题都是比较容易检查的，但也不要忽略这类低级错误的存在。

环境配置引发的报错

这类问题的解决比较复杂，需要仔细检查。我也是在这个地方绕了一圈（说白了还是gradle学艺不精orz）

检查点1:是否需要重新打包

在改写一些前人写的脚本时，可能脚本的源代码只是放在项目中，真正依赖的插件早已是远程仓库中发布的依赖（本人踩坑点其一）。

所以如果要测试，可以根据需要重新将修改后的插件代码打jar包。
打jar包参考：gradle项目发布

打完jar包后进行项目的配置，引入本地仓库中对应插件的依赖。

检查点2:插件依赖重名

在项目中，往往已经引入了远程仓库的插件依赖，这个时候就要解决插件依赖重名的问题。

如果只是插件版本冲突：本地仓库的插件版本已经在远程仓库发布过了，所以需要重新设置版本号；

如果是远程仓库调用过该插件，那么可以有2种解决方案：

第一种，在对应的repositories和dependencies中把仓库和插件写在最前面，这种方式可以不改写原项目引用远程仓库插件的代码，可以保证后续把调试完成的插件发布到远程仓库后依旧可以保持原项目使用。

第二种，直接注释掉原代码中引用的同名依赖即可。

检查点3:添加依赖的位置

检查原项目中引入依赖的位置是在settings.gradle还是build.gradle（本人踩坑点二）。AS在sync的时候执行的配置顺序是：

1. settings.gralde
2. 项目的build.gradle
3. APP的build.gradle

在所以要先检查settings.gradle中是否已经添加了远程仓库中的重名插件，并且如检查点2中一样在该远程仓库的前面添加本地仓库的依赖和插件，不然就算在build.gradle或settings.gradle的后半段中添加了本地仓库的依赖，仍旧会优先掉用远程仓库中的原插件，导致添加或修改的方法调用无法生效（你引入的都是远程仓库的插件了，自然用不到本地仓库修改后的方法）。

这里要注意，AS仍然会检查build.gradle中的本地仓库依赖是否存在，但不会调用。

总结

主要还是本人对gradle的调用顺序不熟悉导致了这次问题。文中如有错误欢迎指出，该问题上发生其他问题也欢迎共同探讨。