I am building a Grails plugin (grails-myorg.zip) that will contain reusable code/artifacts that should be used by every Grails app in our organization. This includes custom CSS/JS files that help give our apps a consistent look-and-feel.
I'm wondering what the best course of action here is:
- Create a
grails-myorg-themes.zip plugin, which just includes the reusable CSS and JS files, and then make that a runtime plugin/dependency (using BuildConfig.groovy) of the main grails-myorg.zip plugin; or
- Put the CSS/JS files in the main
grails-myorg.zip plugin, but then use the Grails resources plugin to configure the files for all downstream dependencies.
Ultimately the only requirement is:
Anytime a developer includes the main grails-myorg.zip plugin as part of their app's plugins, then the custom CSS/JS files will be available (via URL) at runtime to the app's HTML files. This way, they have the option to include CSS styles and other JS stuff - defined inside these common files - in their apps.
Which strategy should I utilize, why and what would the configuration look like?
I don't see a requirement of having grails-myorg-themes plugin if sole purpose of grails-myorg is just to be a provider for resources to a grails app.
Second option looks like a good start for the scenario that has been laid out. If resources change and/or updated, versioning the plugin up would suffice.
What:
- You would not need resources plugin in the plugin, app should be using resources plugin. If at all resources plugin is used in
grails-myorg plugin then it should be excluded in the package by using export = false in build config.
- Create business specific resources modules which can be used in the app effortlessly. For example:
Plugin resources file should have something like below, highlighting dashboard (say, a enterprise wide module which reflects the brand) as a module which can be required in app in specific pages/templates.
//MyOrgResources.groovy
modules = {
dashboard {
resource url: 'js/dashboard/dashboard.js'
resource url: 'css/dashboard/dashboard.css'
}
}
So on and so forth for common domain specific resources.
Why:
The plugin is self explanatory in mentioning that "any enterprise level resource, related to a domain or a module" can be referred from this plugin. In the end, it will be a useful idea only if the plugin is documented and shared appropriately across teams, so that no one re-invents the wheel.
