codeconsole commented on code in PR #16184: URL: https://github.com/apache/grails-core/pull/16184#discussion_r3962838363
########## grails-doc/src/en/guide/upgrading/upgrading80x.adoc: ########## @@ -3025,3 +3025,21 @@ Grails 7 (`org.apache.grails.data:grails-datamapping-async`) coordinates in a pr ---- ./rename_gradle_artifacts.sh -l my/project/location ---- + +==== 53. Grails Plugins Run for a Grails Application Only + +The Grails plugin lifecycle ran for any Spring Boot application that had `grails-core` on its class path, +whether or not it was a Grails application. An application that depended on a Grails library — GSP for its +views, say — was given a `GrailsApplication`, a plugin manager, and the beans of every plugin found on the +class path, over the top of what the libraries it did ask for auto-configure for themselves. + +The lifecycle now runs only for a Grails application: one that `GrailsApp` launched, or one where a source of +the context is a Grails application class, which is what `grails-app/init/Application.groovy` is. A Grails +application is unaffected either way. A Spring Boot application using a Grails library gets that library's +auto-configuration and nothing else. + +This matters if you deliberately put a Grails plugin on the class path of an application that is not a Grails +application and relied on its `doWithSpring` or `beanRegistrar` beans being contributed. Those beans are no Review Comment: Covered in 99cf46fb57, with a before/after example and the note that `@Integration` and the `grails-testing-support` unit test mixins are unaffected. -- 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]
