I personally have not seen this feature used much. I'd bet this overlaps with Spring's @ConditionalOnBeanMissing and having one, may mean we can ditch the eviction process.
On 2026/03/18 17:00:51 Mattias Reichel wrote: > 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? >
