Checked In Plugin Directory

Keep all plugins inside the application directory so they can be checked in with the code.

How

In BuildConfig.groovy add:

grails.project.plugins.dir="./plugins"

The Good

• Easy Setup
• Changes Reload

The Bad

• All or Nothing for Plugins
• Ignores Versions
• Hard to use the power of VCS

The Ugly

• Unclear on what has changed
• Upgrade Pain
• Easy to destroy changes

Inline Plugin

Add a plugin from a local directory.

How

For each plugin add a line like the following in BuildConfig.groovy

grails.plugin.location.'sanitizer' = "./snapshot-plugins/sanitizer"

The Good

• Allows a single local plugin
• Changes Reload
• Can use VCS power

The Bad

• No Versions

The Ugly

• Can use an absolute or relative path not in the repo
• Odd dependency resolution
• Some plugins will work as Inline and not as a normal plugin

Example of Use

// FORKED.
grails.plugin.location.'commentable' = "./plugins/commentable-0.7.3"
grails.plugin.location.'google-visualization' = "./plugins/google-visualization-0.4.2"

// SUBMODULES
grails.plugin.location.'ckeditor' = "./snapshot-plugins/grails-ckeditor"

// UNMODIFIED. Not in main repository. Installed locally.
grails.plugin.location.'image-tools' = "./plugins/image-tools-1.0.4"

Example of Evil

grails.plugin.location.'rlapi' = "../../company_plugins/rlapi"

Leading To

In some build script you get:

if [ -d "$WORKSPACE/company_plugins" ]; then
  cd "$WORKSPACE/company_plugins/rlapi"
  git pull origin
else
  git clone -o origin git@git.example.com:company_plugins "$WORKSPACE/company_plugins"
fi

Custom Repo

Expose the forks and unreleased plugins into a repo, that isn't grails central repo.

How

In BuildConfig.groovy add the repo

grails.project.dependency.resolution = {
    repositories {
        mavenRepo "http://repo.example.org/grails/forks/"
    }
}

The Good

• Supports Versioning
• Dependency resolution works the way the rest of Grails does

The Bad

• Changes don't reload
• Extra step to release changes to the repo

The Ugly

• Takes more time to iterate then it should

Working with Forks

First Identify:

• Expected Life
• Degree of Fork
• Internal Changes

Working with Forks

Tend to adding features allowing customization.

Working with Forks

Create a repo for each plugin. Run CI.

Working with Fork - VCS

• Branch for the changes
• Use submodules to pull in these plugins while working with an inline plugin

Strategy for Unreleased

Why is it unreleased?

Use Bintray

Bintray is a hosted solution you can use to host plugins that haven't been published. But no snapshots.

Use Versioning

Don't just depend on snapshots.