Hello @jamesfredley and @matrei, I have been going through Issue #15469 and the discussion about migrating configuration metadata to @ConfigurationProperties for Grails 8. I find this direction very interesting, especially because it can reduce manual maintenance of spring-configuration-metadata.json and improve IDE support through automatically generated metadata.
>From what I understood, one possible way to approach this could be starting with the modules that already use @ConfigurationProperties and enabling the spring-boot-configuration-processor there first, so we can quickly remove manual metadata maintenance in those areas. After that, for modules still using Groovy DSL configuration (for example, DefaultSecurityConfig.groovy and parts of application.groovy), it might be possible to gradually introduce strongly typed configuration classes while keeping backward compatibility, so existing projects are not affected. For cases where Groovy DSL flexibility is important, I was also curious whether a Grails-specific configuration processor using AST transforms could help keep Groovy’s expressive style while still generating reliable metadata automatically. I wanted to better understand how the team is thinking about the long-term direction here. Do you see Grails moving towards a hybrid model where Groovy DSL and @ConfigurationProperties coexist, or is the intention to gradually align more closely with Spring Boot’s type-safe configuration style? I am currently studying this area to understand how I can contribute effectively to Issue #15469, and I would really appreciate your thoughts on whether this kind of incremental approach makes sense. Thank you for your guidance.
