kebab-case support in app generation

[gsartori]

Description

Currently, several Grails configuration properties use camelCase naming conventions such as:

maxFileSize
driverClassName
useFilter
storeDir

while the broader Spring ecosystem consistently adopts kebab-case naming, for example:

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:

server:
  servlet:
    session:
      store-dir: appname

grails:
  controllers:
    upload:
      max-file-size: 20MB

instead of:

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.

[matrei]

+1

[jdaugherty]

its my understanding we support either?

[gsartori]

@jdaugherty it should work out of the box, so we could just change the styling in the generated files and documentation. I don't know though if that is true for all the config properties. Maybe some of them are hardcoded?

[gsartori]

On a further analysis I can confirm GORM has hardcoded properties, for example:

• HibernateConnectionSourceSettings
• DataSourceSettings
• Possibly other locations are affected

For GORM's own properties camelCase is used
For setting Hibernate properties snake_case is used

Other than that I've converted a full application.yml and the application runs with no Exceptions.

Plugins may require further investigation.

I guess this is a long term goal.

[jdaugherty]

@gsartori the reason the default generated files do not show kebab out of the box is because kebab doesn't work with the application.groovy usages. If you're using application.yml, yes it should already work since we convert to either when reading the configuration files. Now, with Grails 7 there may be a regression in this area where both forms are not supported - if so, we need to revisit this. Are you saying you have a reproducer where kebab isn't working in application.yml?

As long as we also support application.groovy, I'm against this being a default. We could, however, enhance forge to support making it a default based on a user preference.

[jdaugherty]

I should have been more clear here: internally the framework uses non-kebab case, but due to the way we load configuration, it's supposed to add both forms. i.e. if the grails configuration is 'fooBob', then either foo-bob or fooBob should work. This is actually a feature of Spring Boot, you can read about it here. saying that Spring Boot is kebab by default is misleading since they support both too.

[gsartori]

In a forged application, converting the properties to kebab-case worked for all properties except for dataSource and dbCreate. If you change them the application wont start.

Thinking about it though, one reason to keep the camelCase would be to aid searching in files.

I don't know, I still feel that kebab-case fits better with a configuration file, but that may just be me.

Correct me if I'm wrong, you are saying that we could use camelCase in the application.groovy while keeping the kebab-case in the application.yml (given the above issue with GORM is solved) ?

[jdaugherty]

I'm saying it's up to the end user which case they use, which is why I think it's better to enhance forge for letting the user select it. We have a lot of configuration changes coming down the pipeline already - we want to make documentation easier so I think this ticket fits inside of that goal.

As for it not being supported in certain paths, that's clearly a bug that we need to understand why it doesn't work either way.