18.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 called dependsOn. For example, take a look at this snippet from the Hibernate plugin:

  1. class HibernateGrailsPlugin {
  2. def version = "1.0"
  3. def dependsOn = [dataSource: "1.0",
  4. domainClass: "1.0",
  5. i18n: "1.0",
  6. core: "1.0"]
  7. }

The Hibernate plugin is dependent on the presence of four plugins: the 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:

  1. def dependsOn = [foo: "* > 1.0"]
  2. def dependsOn = [foo: "1.0 > 1.1"]
  3. def dependsOn = [foo: "1.0 > *"]

When the wildcard * character is used it denotes "any" version. The expression syntax also excludes any suffixes such as -BETA, -ALPHA etc. so for example the expression "1.0 > 1.1" would match any of the following versions:

  • 1.1

  • 1.0

  • 1.0.1

  • 1.0.3-SNAPSHOT

  • 1.1-BETA2

Controlling Load Order

Using dependsOn 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:

  1. def loadAfter = ['controllers']

Here the plugin will be loaded after the 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:

  1. if (manager?.hasGrailsPlugin("controllers")) {
  2. openSessionInViewInterceptor(OpenSessionInViewInterceptor) {
  3. flushMode = HibernateAccessor.FLUSH_MANUAL
  4. sessionFactory = sessionFactory
  5. }
  6. grailsUrlHandlerMapping.interceptors << openSessionInViewInterceptor
  7. }

Here the Hibernate plugin will only register an 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:

  1. 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:

  1. def environments = ['development', 'test', 'myCustomEnv']
  2. def scopes = [excludes:'war']

In this example, the plugin will only load in the 'development' and 'test' environments. Nor will it be packaged into the WAR file, because it’s excluded from the 'war' phase. This allows 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 tests

  • functional-test - when running functional tests

  • run - for run-app and run-war

  • war - when packaging the application as a WAR file

  • all - plugin applies to all scopes (default)

Both properties can be one of:

  • 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

For example,

  1. def environments = "test"

will only include the plugin in the test environment, whereas

  1. def environments = ["development", "test"]

will include it in both the development and test environments. Finally,

  1. def environments = [includes: ["development", "test"]]

will do the same thing.