This raises an ugly prospect: a new resource dependency problem. Only unlike java dependency problems this is worse as you end up with multiple copies of resources in your app, even if they are the same version because plugins will typically bundle the resources themselves. Your app may add some of these too and your site becomes slow to load or experiences failures related to clashing library versions.
There is however a staggeringly simple solution to this: lightweight Grails plugins that contain the resources.
Thanks to Grails’ automatic dependency resolution we (the grails community) can just create plugins to wrap up each such library and then we just make any apps or plugins that require them depend on them by installing the library plugin or adding it to the dependsOn clause of other plugins.
An important caveat here is that the library plugins need to use version numbers matching the version of the library they encapsulate. Then if you want jQuery 1.4.2 you depend on/install grails-jquery version 1.4.2 or higher. The grails-jquery plugin authors have already done this.
These plugins should implement a simple tag called “resources” in an appropriate namespace e.g. or .
I strongly believe that such plugins should NOT include other tags or more heavyweight tags wrapping up library features – do that in another plugin e.g. “grails-jquery-tools”.
This approach does provide new challenges for optimizing static content – minifying JS and CSS and including only required modules from a larger library remains awkward as it is today with non-dependency solutions.
Ultimately I think we need smarter solutions than those currently in use to solve this. I have some ideas forming…