17.9 Understanding Plugin Load Order - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari
Version: 3.0.11
17.9 Understanding Plugin Load Order
Controlling Plugin Dependencies
Plugins often depend on the presence of other plugins and can adapt depending on the presence of others. This is implemented with two properties. The first is calleddependsOn
. For example, take a look at this snippet from the Hibernate plugin:class HibernateGrailsPlugin { def version = "1.0" def dependsOn = [dataSource: "1.0", domainClass: "1.0", i18n: "1.0", core: "1.0"] }
dataSource
, domainClass
, i18n
and core
plugins.The dependencies will be loaded before the Hibernate plugin and if all dependencies do not load, then the plugin will not load.The dependsOn
property also supports a mini expression language for specifying version ranges. A few examples of the syntax can be seen below:def dependsOn = [foo: "* > 1.0"] def dependsOn = [foo: "1.0 > 1.1"] def dependsOn = [foo: "1.0 > *"]
- 1.1
- 1.0
- 1.0.1
- 1.0.3-SNAPSHOT
- 1.1-BETA2
Controlling Load Order
UsingdependsOn
establishes a "hard" dependency in that if the dependency is not resolved, the plugin will give up and won't load. It is possible though to have a weaker dependency using the loadAfter
and loadBefore
properties:def loadAfter = ['controllers']
controllers
plugin if it exists, otherwise it will just be loaded. The plugin can then adapt to the presence of the other plugin, for example the Hibernate plugin has this code in its doWithSpring
closure:if (manager?.hasGrailsPlugin("controllers")) { openSessionInViewInterceptor(OpenSessionInViewInterceptor) { flushMode = HibernateAccessor.FLUSH_MANUAL sessionFactory = sessionFactory } grailsUrlHandlerMapping.interceptors << openSessionInViewInterceptor }
OpenSessionInViewInterceptor
if the controllers
plugin has been loaded. The manager
variable is an instance of the GrailsPluginManager interface and it provides methods to interact with other plugins.You can also use the loadBefore
property to specify one or more plugins that your plugin should load before:def loadBefore = ['rabbitmq']
Scopes and Environments
It's not only plugin load order that you can control. You can also specify which environments your plugin should be loaded in and which scopes (stages of a build). Simply declare one or both of these properties in your plugin descriptor:def environments = ['development', 'test', 'myCustomEnv'] def scopes = [excludes:'war']
development-only
plugins to not be packaged for production use.The full list of available scopes are defined by the enum BuildScope, but here's a summary:
test
- when running testsfunctional-test
- when running functional testsrun
- for run-app and run-warwar
- when packaging the application as a WAR fileall
- plugin applies to all scopes (default)
- a string - a sole inclusion
- a list - a list of environments or scopes to include
- a map - for full control, with 'includes' and/or 'excludes' keys that can have string or list values
def environments = "test"
def environments = ["development", "test"]
def environments = [includes: ["development", "test"]]