You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we have gone through the upgrade of Grails 7, we have noticed a lot of empty / default generated files. One of Grail's core principles is convention over configuration. The default, empty Bootstrap file is a good example of not adhering to this principle. However, for functional testing, we need to make sure there is test coverage for grails supported features.
We could remove the empty Bootstrap classes, and leave them in one spot with a comment on why an empty one exists. However, after investigating the changes to the Application class, Spring has taken an alternative approach. Spring uses the application class as a bootstrap class. I can't think of a reason why we couldn't do something similar.
This ticket would remove the Bootstrap.groovy support and integrate it into the Application class instance. This is a post 7.0 goal.
The text was updated successfully, but these errors were encountered:
doWithSpring already exists on the application class, so this would simplify that setup.
As part of this cleanup, I would suggest changing the closures like doWithSpring, init, etc to be methods so that the GrailsAutoConfiguration class can define base implementations so developers can have better IDE support of what's possible to define.
Issue description
As we have gone through the upgrade of Grails 7, we have noticed a lot of empty / default generated files. One of Grail's core principles is convention over configuration. The default, empty Bootstrap file is a good example of not adhering to this principle. However, for functional testing, we need to make sure there is test coverage for grails supported features.
We could remove the empty Bootstrap classes, and leave them in one spot with a comment on why an empty one exists. However, after investigating the changes to the Application class, Spring has taken an alternative approach. Spring uses the application class as a bootstrap class. I can't think of a reason why we couldn't do something similar.
This ticket would remove the Bootstrap.groovy support and integrate it into the Application class instance. This is a post 7.0 goal.
The text was updated successfully, but these errors were encountered: