Curious, is there a use case nowadays for having one plugin evict another?
Den lör 14 mars 2026 kl 17:56 skrev James Daugherty <[email protected]>: > > 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?
