jdaugherty commented on code in PR #16434:
URL: https://github.com/apache/grails-core/pull/16434#discussion_r4145662074
##########
grails-core/src/cli/groovy/org/apache/grails/core/cli/ConfigReportCommand.groovy:
##########
@@ -202,12 +206,26 @@ class ConfigReportCommand implements ApplicationCommand {
}
MetadataResult loadPropertyMetadata() {
- Enumeration<URL> resources =
ConfigReportCommand.classLoader.getResources('META-INF/spring-configuration-metadata.json')
+ loadPropertyMetadata(ConfigReportCommand.classLoader)
+ }
+
+ /**
+ * Loads the configuration metadata on the classpath of the given class
loader. Properties outside the Grails
+ * namespaces are only included when they are published by a Grails
plugin, so that the metadata of other
+ * libraries, such as Spring Boot, does not flood the report.
+ *
+ * @param classLoader the class loader to load the metadata from
+ * @return the properties and group descriptions
+ */
+ MetadataResult loadPropertyMetadata(ClassLoader classLoader) {
+ Set<String> pluginRoots = findPluginRoots(classLoader)
+ Enumeration<URL> resources =
classLoader.getResources(METADATA_RESOURCE)
List<ConfigPropertyMetadata> metadata = new
ArrayList<ConfigPropertyMetadata>()
Map<String, String> groupDescriptions = new LinkedHashMap<String,
String>()
JsonSlurper slurper = new JsonSlurper()
while (resources.hasMoreElements()) {
URL resource = resources.nextElement()
+ boolean pluginMetadata =
pluginRoots.contains(resourceRoot(resource, METADATA_RESOURCE))
Review Comment:
The descriptor and the metadata file do not always share a root.
`META-INF/grails-plugin.xml` is written by
`GlobalGrailsClassInjectorTransformation` into the compiler target directory,
i.e. the Groovy classes output. A hand-written
`src/main/resources/META-INF/spring-configuration-metadata.json` (which is how
`grails-inertia-plugin` publishes its metadata) is processed into
`build/resources/main`. Inside a jar both end up under one root and this check
works. When the plugin is on the classpath as directories they are two
different roots, so the lookup never matches and the plugin's properties are
dropped again.
I confirmed it with a variant of your test: one `classpathRoot` holding only
the descriptor and a second holding only the metadata JSON, both in the same
`URLClassLoader`. `acme.enabled` is absent.
Where this shows up:
- a plugin project running `configReport` on itself, since
`ClasspathUtils.buildClasspath` puts its own classes dirs and
`build/resources/main` on the command classpath
- plugins consumed through the exploded variant, which
`GrailsExtension.isDevelopmentRun()` selects for `bootRun`/`console` in
development mode or with `-Pforce.grails.exploded`
Plain `./gradlew configReport` resolves plugin project dependencies as jars,
so the common path is fine.
I don't think this needs to hold up the PR, but it should either be stated
as a limitation in the guide paragraph you added ("in its JAR" is doing quiet
work there) or tracked as a follow-up. A "treat every directory root as plugin
metadata" fallback would also pull the application's own typed properties out
of Other Properties, which the config-report integration example currently
asserts, so that widening is a design choice rather than a quick fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
