From https://github.com/grails/grails-gradle-plugin/issues/340#issuecomment-2428033590 , there's previous discussion about splitting the grails gradle plugin.
The side effects from having a core grails plugin that assumes an entire runable grails app causes excess time in compiling for grails plugins that are not runable. We identified that grails-core already takes the approach of not including the gradle plugin because of this issue.
#13968 (comment) gives further reason for this need.
At a high level, here's what we currently have (simplified view for illustration approaches):
grails 'core' shared gradle plugin
- adds spring boot
- changes tasks
- adds dependency plugin
- wires up different classpath
- etc
grails plugin gradle plugin
- extends core
- and generates the metadata
- which means any plugin gets the kitchen sink, even if it doesn't need to be a runable app
grails web
- extends core
- injects tag libs, registers tag libs, etc
grails gsp
- extends core
- compiles gsp
We need to split grails plugin gradle plugin separate from the shared grails gradle plugin. We can leave a composite plugin that groups many plugins like the existing grails plugin gradle plugin so it doesn't break existing plugins. The goal of this split would enable people to layer functionality in plugins. need only views? apply only the view plugin. need it a full grails app? apply the set of plugins that make it a full grails app?
This would also have the added benefit of making the gradle plugins not be a magic black box for people. You would know what's causing the gradle behavior and would make it easier for new grails developers to understand what's going on. This split would require a significant amount of documentation to ensure people understand when to use what plugin (instead of the current approach, which is effectively always use everything since the logic is in the core plugin that no one ever includes).
From https://github.com/grails/grails-gradle-plugin/issues/340#issuecomment-2428033590 , there's previous discussion about splitting the grails gradle plugin.
The side effects from having a core grails plugin that assumes an entire runable grails app causes excess time in compiling for grails plugins that are not runable. We identified that grails-core already takes the approach of not including the gradle plugin because of this issue.
#13968 (comment) gives further reason for this need.
At a high level, here's what we currently have (simplified view for illustration approaches):
We need to split grails plugin gradle plugin separate from the shared grails gradle plugin. We can leave a
compositeplugin that groups many plugins like the existing grails plugin gradle plugin so it doesn't break existing plugins. The goal of this split would enable people to layer functionality in plugins. need only views? apply only the view plugin. need it a full grails app? apply the set of plugins that make it a full grails app?This would also have the added benefit of making the gradle plugins not be a magic black box for people. You would know what's causing the gradle behavior and would make it easier for new grails developers to understand what's going on. This split would require a significant amount of documentation to ensure people understand when to use what plugin (instead of the current approach, which is effectively always use everything since the logic is in the core plugin that no one ever includes).