Split Grails Gradle Plugins & Use Composition

[jdaugherty]

From #340 (comment) , 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.

grails/grails-core#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).

[jdaugherty]

to be clear, by composition I mean we would have a plugin that includes the split plugins ... we could even have the composed plugin be the same name so it's backwards compatible. Going forward people could then include only the plugins they need to implement a grails plugin.

This has the huge benefit that people only have to rewrite a plugin when they use a function that was changed by grails.