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?

Reply via email to