matrei commented on PR #15518:
URL: https://github.com/apache/grails-core/pull/15518#issuecomment-4102919578
> My only worry is now you have a plugin that people think they can load
before, evict, etc and yet they cannot. We have other libraries that do not
have plugins in them but add significant functionality (look at
grails-web-common). It would be nice as part of any re-architecture of the
plugins if we could address this.
- Does bean registration have to correlate with plugin load ordering, or can
we let the features available for the Spring context handle that for us?
`@Conditional*`, `@Lazy`, `ObjectProvider<T>` etc.
- What would be the use case for loading before `dataBinding`?
- Is there a use case nowadays for having one plugin evict another? I see
this as problematic in conjunction with `@Configuration` as beans will already
be registered when eviction starts. Doesn't it make more sense to just remove
the plugin dependency in the application. Maybe we can stop startup with a
message if "evicted" (incompatible) plugins are on the classpath?
- I don't see any plugin "traits" in `grails-web-common`. (I may be missing
something)
Plugin "traits" as I see them (one or more of):
- Grails artefacts (controllers, url-mappings, services, taglibs, cli
commands etc.)
- Beans registered in the application context
- Application resources
- Lifecycle event handlers
- Trait injectors*
- Groovy Extension Modules*
- Metadata
- Title
- Description
- Author
- Grails version compatibility range
- License
- Documentation url
- Scm details
\* This is not a plugin trait in and of itself, but can be part of a plugin
--
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]
