Grails 5.1.7多插件依赖传递访问失效问题技术问询

我在处理Grails版本升级时也遇到过类似的问题，结合对Grails 5架构变化的了解，给你整理下问题的背景和可行的解决方案：

问题背景 #

预期行为 #

主应用A依赖插件B，插件B又依赖插件C。按照依赖传递的逻辑，主应用A应该能直接访问插件C里的服务、文件或者依赖项——这套逻辑在Grails 3.1.6和3.3版本里跑的很顺畅，所以升级到5.1.7后也应该正常工作。

实际行为 #

但在从Grails 3.1.6升级到5.1.7的过程中，我们发现用同样的依赖配置，主应用A完全访问不到插件C里的文件，这和旧版本的表现完全不一样。

环境信息 #

• macOS Monterey：OpenJDK Zulu版本1.8.0_332-b09
• Windows 10：OpenJDK版本1.8.0_181

问题根源分析 #

Grails 5是基于Spring Boot 2.x重构的，和Grails 3.x相比，类路径管理、资源加载以及插件依赖传递的机制都有不小的变化。在Grails 3.x中，插件的资源默认会自动传递给上层依赖的应用，但Grails 5为了优化资源加载效率，默认限制了插件资源的暴露范围，间接依赖的插件资源不会自动被上层应用识别。

可行的解决方案 #

1. 显式配置插件C的资源暴露 #

在插件C的grails-app/conf/application.yml里，添加资源暴露的配置，让它的所有资源都能被上层依赖访问：

grails:
  resources:
    expose:
      - "**/*"

你可以根据实际需求调整通配符，比如只暴露特定目录下的资源，比如"grails-app/services/**/*"。

2. 确认依赖传递的配置正确 #

检查插件B的build.gradle里，对插件C的依赖是否用了正确的配置，确保依赖能传递到主应用A：

dependencies {
    implementation project(":pluginC")
}

千万别用compileOnly或者runtimeOnly，这两种配置会阻断依赖的传递性，导致主应用A看不到插件C的资源。

3. 调试类路径加载情况 #

如果还是有问题，可以在主应用A里加一段调试代码，看看插件C的资源有没有被加载到类路径里：

def resource = grailsApplication.mainContext.getResource("classpath:/path/to/your/pluginC/file.txt")
println "插件C的资源是否存在：${resource.exists()}"

通过这个输出能快速定位是资源没打包进去，还是加载路径有问题。

4. 检查插件C的打包配置 #

确保插件C的build.gradle里开启了资源打包的功能，这样资源才会被正确打包到插件JAR里：

grails {
    plugin {
        features {
            resources true
        }
    }
}

这个配置是Grails 5插件打包时必须的，否则资源不会被包含在插件包中。

总结 #

总的来说，这个问题就是Grails 5对插件资源的默认暴露策略变了，只要显式配置资源暴露，同时确保依赖传递的正确性，就能解决主应用访问间接依赖插件资源的问题。

内容的提问来源于stack exchange，提问作者Suresh Ghatuwa