1

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?

AdjustingForInflation
  • 1,571
  • 2
  • 26
  • 50

1 Answers1

2

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.

dmahapatro
  • 49,365
  • 7
  • 88
  • 117
  • 1
    +1. My opinion is that the split is only good if you want to separate them by feature, and the master plugin will have nothing to do with UI. –  Apr 08 '14 at 03:31
  • Thanks @dmahapatro (+1) - but (1) how would I make `dashboard` a `required` module for any Grails app using this plugin? And (2) I guess I don't fully understand the resources plugin: if the CSS/JS module is defined in the plugin, why do I need to utilize the resources plugin from the **app** and not the plugin? Thanks again! – AdjustingForInflation Apr 08 '14 at 11:01
  • 1. The same way any module in app `dependOn` any other module. You can refer docs about `dependsOn`. 2. You can do both. `dahsboard` module not only can be used in the plugin if required but also in the app where the plugin is used. Regarding the usage of resources plugin, you can get an in-depth idea by [going through the docs in detail](http://grails-plugins.github.io/grails-resources/). – dmahapatro Apr 08 '14 at 13:13