Presenter: Graeme Rocher

Agenda

• plugin quick start
• technical vs. functional plugins
• plugins for modularity
• distribution and dependency management
• plugin demo

Key Facts

• grails itself is made up of a collection of plugins

  • hibernate, webflow, gsp, etc.
  • grails core is essentially a set of plugins (about a dozen)

• there are 300+ plugins available now

  • what a plugin can do is wide and varied

• plugins are easy to create

  • don’t need to spend a ton of time learning the internals of the framework to create a plugin

• plugins are easy to distribute
• everyone is a plugin developer
• well over 25 million lines of user contributed code in the plugin repository

  • searchable

    • automatically makes any domain class searchable

  • taggable

    • adds apis to tag domain classes

  • rateable

    • ratings for domain classes

  • quartz

    • for scheduling tasks
    • interesting because it adds a new concept to grails — “jobs”
    • adds create-job command to command line, has a jobs directory, etc.

  • gwt
  • weceem cms

    • example of a functional plugin as opposed to just providing new apis
    • this plugin contains views, controllers, domains, etc. as part of the plugin

  • feeds (rss and atom feeds)
  • iwebkit (iphone)

Common Use Case

• you have a tag library
• you have two applications
• you want to share functionality
• create a plugin!
• grails create-plugin pluginName creates the plugin skeleton
• grails 1.2 creates intellij project files

Plugin Structure

• more or less identical to a grails application structure
• can run the plugins as standalone apps

  • developing a plugin is the same as developing an application

• only real difference is there’s a plugin descriptor in the root of each plugin

  • contains info about plugin version, grails versions supported
  • can also exclude specific resources when the plugin is installed
  • also numerous plugin hooks that can be accessed (doWithWebDescriptor, doWithSpring, etc.)

• using packages is important–should always uses packages in your applications

Plugin Quick Start — 5 steps

• grails create-plugin myPlugin
• cd myPlugin
• grails create-tag-lib myTagLib
• grails package-plugin
• grails install-plugin

Plugin Extension Points

• normal grails development

  • tag libraries, controllers, etc.
  • the build
  • theses are very trivial to do

• requires additional knowledge

  • spring configuration
  • new apis

    • addition of additional properties/methods to domain classes and domain controllers

  • new concepts

Plugin Types

• relate to the “split” above
• functional plugins

  • taglibs, controllers, extend the build, etc.

• technical plugins

  • see above–spring config, metaprogramming, etc.

Examples

• functional plugins

  • weceem cms
  • nimble

    • provides user management, integration with facebook, etc.

• technical plugins

  • gwt
  • functional test

• both functional and technical

  • spring security
  • searchable

    • adds search to domain classes, but also provides a complete search UI to your application

Functional Plugins

• easier to understand
• just like building a normal grails application
• silos of functionality

  • forums, blog, search, etc.

• used to create modular applications

Demo: Building a Functional Plugin

• example: twitter clone

  • two different teams–web UI team, mobile team
  • underlying functionality is the same

• good candidate for a plugin–need to share the domain model between the two apps
• can install plugins in other plugins

  • e.g. can install both the iwebkit and the twitter domain model plugin into the iphone version of the app
  • can specify plugins and versions in dependsOn block in the plugin descriptor
  • when you package up your plugin it will bundle up the plugins on which your plugin depends and include them

• can use BootStrap.groovy within plugins
• can configure local plugin repositories and can specify order in which plugin repositories are searched

Certain Things that Plugins Cannot Package by Default

• BootStrap.groovy, UrlMappings.groovy, DataSource.groovy
• can create something like FooUrlMappings.groovy and that will get packaged

Some Tips

• inline plugins

  • if you’re modularizing your entire application, becomes impractical to repackage and reinstall every plugin as they change during development

• url mappings
• jar dependencies
• testing
• plugin distribution

Inline Plugins

• use plugins without installing them
• prevents package/install cycle
• great for modular application development
• go to grails-app/conf/BuildConfig.groovy and set grails.plugin.location.”pluginName”=”../path/to/plugin”
• BuildConfig.groovy

  • not generated automatically in 1.1.1
  • lets you configure various aspects of the build, locations of generated files, etc.

URL Mappings

• normal UrlMappings.groovy file is excluded from the package plugin process
• if you want to define url mappings as part of your plugin, create a file called something like MyPluginUrlMappings.groovy and that will be included

Plugin Dependencies

• grails supports transitive installs and plugin dependencies using dependsOn
• can use ranges of versions for dependencies, e.g. hibernate:”1.1 > *”
• to implement a “soft” dependency use loadAfter

  • def loadAfter = [“hibernate”]
  • can also specify loadBefore

Plugin JAR Dependencies

• you can put jar files in the lib directory of the project just like applications
• even better, in grails 1.2 you can define dependencies in grails-app/conf/BuildConfig.groovy
• grails.project.dependency.resolution = {
  inherits “global” // inherit grails’ default dependencies
  dependencies {
  runtime “org.apache.ant:ant:1.7.1”
  }
  }
• different scopes can be involved–build, runtime, test, provided (needed during grails run-app but not during WAR deployment)
• this means the jar files are NOT included in the plugin packaging

  • allows application into which the application is installed to resolve the dependencies

• in a traditional java project, the jar dependency list is flat
• in grails, you have dependencies of the app, of the framework, and of any plugins involved

Testing

• done just like a normal application
• sometimes it’s useful to have classes used only for testing and not distributed with the plugin
• use pluginExcludes in the plugin descriptor to achieve this
• class MyPlugin {
  def pluginExcludes = [
  “ant/path/here“
  ]
  }

Plugin Distribution

• central repository

  • grails release-plugin

• custom repository

  • can configure custom repos in BuildConfig.groovy
  • can also set this in settings.groovy in your user home directory

• Grails separates notion of repos used for discovery vs. distribution (e.g. http for discovery, https for distribution)
• can specify the repository into which to release the plugin when you run grails release-plugin
• custom repos use svn for distribution

  • can use a basic file server for discovery

• plugins don’t necessarily have to be open source to be in the central repository

  • need to specify the license
  • would distribute jars instead of source

Summary

• developing grails plugins is very simple
• functional plugins are an easy way to modularize your application
• in part 2 we’ll be looking at how to develop technical plugins

Q&A

• as part of modularization is there any integration with osgi?

  • not yet, but looking into it–probably next year there will be something more concrete

• are there particular plugins that you would highlight that follow best practices or as good models to follow?

  • depends on what you want to do
  • for a functional plugin check out weceem cms–complete end-to-end with views, js, etc.
  • for a technical plugin check out Build Test Data (creates mock data for you)
  • quartz plugin is a good example of a plugin that adds a new concept to grails, new command line arguments, etc.

    • exercises the artefact api

  • SpringWS plugin adds notion of an endpoint to Grails
  • Ratable, Commentable, Featurable, and Taggable are great examples of modifying domain classes on app load