vigneshsiva11 commented on issue #15469: URL: https://github.com/apache/grails-core/issues/15469#issuecomment-4123111664
Hello @jamesfredley and @matrei , I have been studying Issue #15469 and the discussion around migrating configuration metadata to @ConfigurationProperties for Grails 8. The idea of reducing manual maintenance of spring-configuration-metadata.json and preventing configuration drift through automatically generated metadata seems very valuable, especially for improving IDE support and consistency across modules. From my understanding, an incremental migration strategy might help minimize risk while improving maintainability: Proposed approach for clarification: 1. Phase 1 – Immediate improvements in existing @ConfigurationProperties modules: Begin by enabling the spring-boot-configuration-processor in modules that already define configuration using @ConfigurationProperties (such as grails-cache, grails-databinding, grails-views-gson, etc.). This could quickly eliminate manual metadata drift without requiring structural changes. 2. Phase 2 – Gradual refactoring of Groovy DSL configuration: For configurations currently defined using Groovy DSL (for example, DefaultSecurityConfig.groovy and configuration closures in application.groovy), introduce equivalent strongly-typed configuration classes while preserving backward compatibility with existing configuration structures. 3. Phase 3 – Handling Groovy-specific Flexibility: Since Groovy DSL allows dynamic constructs such as closures and GStrings, I was wondering whether a Grails-specific configuration processor using AST transforms could provide a bridge between Groovy's flexibility and structured metadata generation. This could allow Grails to maintain its expressive configuration style while still benefiting from compile-time metadata generation similar to Spring Boot. Clarification I am hoping to understand: • Does the team envision long-term coexistence of Groovy DSL configuration and @ConfigurationProperties-based configuration? • Would the migration mainly focus on improving metadata generation, or is there also an intention to gradually standardize configuration structure across Grails modules? • In the context of AST-based processing, would the goal be to replicate Spring Boot metadata generation behavior or potentially extend it to better support Groovy DSL patterns? I am currently exploring this area to understand how I can contribute effectively to Issue #15469, and I would really appreciate any guidance on whether this phased approach aligns with the intended direction. Thank you for your time. -- 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]
