jdaugherty commented on PR #15407: URL: https://github.com/apache/grails-core/pull/15407#issuecomment-3929085610
I see 4 issues based on these diffs: 1. the code I pushed to pull the properties needs to use the environment instead of application.config 2. documenting external configuration values that aren't in grails-core 3. gorm has different settings depending on the library imported 4. defaults in code that aren't really in configuration I've pushed a fix for the first. For plugins like asset-pipeline, we should not be adding this to grails-core docs. They can change at any time. For cases where the defaults vary (i.e. mongodb vs hibernate have different values), this is the strongest indicator we should not be publishing a static document. For the remaining issue, technically, it's "not" configured but it's using a default. If we take the [plugin.yml fix](https://github.com/apache/grails-core/pull/15409), we can check in plugin configuration and remove the defaults from the plugin code. Then they'll show and be maintained. We can even use your initial effort to figure out what to check in, where. I *am* okay with compromising here though. Use the configuration command to get the configured values, and then make it aware of the defaults (hard code them to start). Then we can gradually move the defaults in the command to actual config and iterate. But to solve the dynamic differences, we'll have to permute your document. We also need to figure out if longer term we want to allow the defaults in code instead of plugin configuration. If we do, we'll need a standard way to do this so we can parse the classpath to find them. This is probably out of scope of the first pass. But we should consider using codenarc to enforce whatever we decide here - if we force configuration files, it should enforce that default is specified in the plugin config instead of inline in the code. -- 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]
