Historically, the Grails Plugin provided build related configuration - like documentation. That is long gone now though - we removed the remnants in 7.0. I raised similar concerns to the Grails Plugin contract in the weekly and we opened https://github.com/apache/grails-core/issues/15498 as a result.
Some other features of the Grails Plugin: 1. Separate from the Spring Lifecycle, plugins have historically used onChange() / Grails specific events to respond for reloading scenarios. I don't think there are equivalent options in Spring (See GrailsApp.groovy developmentModeActive handling). 2. eviction notices - the ability to add multiple plugins and have one of them evict the other 3. By separating the Grails Plugin into its own architecture, we as a framework can control the order. I think we need to do a much better job here - the fact that the CoreGrailsPlugin doesn't load before anything by default (unless otherwise configured) is likely a bug. 4. The plugin process allows us to not only inject Grails artefacts, but a lot of the Grails code base is designed around plugin path artifact handling. i.e. if 2 plugins provide the same gsp, how would we solve this in Spring? 5. One of the "quirks" of the current process is that the load order of the plugin is different from the load order of the artifacts. Looking back at the tickets, numerous issues have been addressed related to this handling. I'm not sure how we would handle that with Spring. >From the Spring side, the equivalent of a Grails Plugin is really Spring's AutoConfiguration + build metadata. They provide all of their configuration via beans & the AutoConfiguration class can declare ordering requirements. The artifact ordering and loading is up to the end user though. Since we're trying to provide an ecosystem, I think we probably want to continue to manage our own plugin process. It can be built on Spring, but I don't think we want to tell people to use Spring only implementations. The only way I see that simplification working is if we integrate better with Spring - there are many examples of this, but 2 are: 1. Grails controllers are not Spring controllers 2. we override the spring dispatcher instead of using theirs. On Thu, Mar 12, 2026 at 6:58 AM Mattias Reichel <[email protected]> wrote: > > Looking at https://github.com/apache/grails-core/pull/15409, I started > to think about the Grails Plugin contract/interface and how we might > want to model it longer term. > > Is there some aspect of Plugin loading and ordering that cannot be > accomplished by leveraging the features of the Spring application > context by itself, by using `@Conditional*`, `@Primary`, `@Lazy`, > `ObjectProvider`, etc.? > > Broadly speaking, today a Grails Plugin is, or contributes one or more of: > > - Grails artefacts (controllers, url-mappings, services, taglibs, cli > commands etc.) > - Beans registered in the application context > - Resources > - Lifecycle event handlers > - Trait injectors > - Groovy Extension Modules (this is not specific to Grails Plugins) > - Metadata > - Title > - Description > - Author > - Grails version compatibility range > - License > - Documentation url > - Scm details > > Am I missing something? > > Would it be possible to reshape/simplify the Grails Plugin > architecture/loading, leveraging modern Spring/Spring Boot?
