gsartori opened a new issue, #15660:
URL: https://github.com/apache/grails-core/issues/15660
### Feature description
### Description
Currently, several Grails configuration properties use camelCase naming
conventions such as:
```yaml
maxFileSize
driverClassName
useFilter
storeDir
```
while the broader Spring ecosystem consistently adopts kebab-case naming,
for example:
```yaml
max-file-size
driver-class-name
use-filter
store-dir
```
Since Grails is built on top of Spring Boot, it would improve consistency
and developer experience if Grails configuration properties fully embraced the
Spring-style kebab-case convention across the framework and official
documentation.
### Why this matters
Using a uniform naming convention would provide several benefits:
* Better alignment with Spring Boot standards
* Improved readability of configuration files
* Easier onboarding for Spring developers using Grails
* Reduced cognitive friction when mixing Grails and Spring configuration
* Cleaner IDE metadata and autocomplete consistency
### Suggested behavior
Ideally, Grails should:
1. Officially support kebab-case aliases for all framework configuration
properties
2. Prefer kebab-case in documentation and generated examples
3. Keep backward compatibility with existing camelCase properties
For example:
```yaml
server:
servlet:
session:
store-dir: appname
grails:
controllers:
upload:
max-file-size: 20MB
```
instead of:
```yaml
server:
servlet:
session:
storeDir: appname
grails:
controllers:
upload:
maxFileSize: 20MB
```
### Additional note
Spring Boot already supports relaxed binding internally, so in many cases
both formats may already work. However, Grails examples, plugins, generated
configs, and official conventions still largely use camelCase. Standardizing on
kebab-case would modernize the configuration style and align Grails more
closely with the Spring ecosystem.
--
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]
