(Quick Reference)

publish-plugin

Purpose

Publishes a Grails plugin to a plugin repository and notifies an associated plugin portal of the release.

Options

grails publish-plugin [--dryRun] [--snapshot] [--repository=repoId]
                      [--protocol=protocol] [--portal=portal] [--pingOnly]
                      [--scm] [--noScm] [--binary] [--no-overwrite] [--allow-overwrite]
  • dryRun will simply print out what files will be deployed. It won't actually perform the deployment, so it's a good way to see whether the command will do what you expect.
  • snapshot forces the command to treat the plugin as a snapshot version. In other words, it will not be marked as the latest release. This currently only affects deployments to Subversion repositories. By default, plugins are treated as release versions unless their version number has a '-SNAPSHOT' suffix.
  • repository specifies which Subversion or Maven-compatible repository the plugin should be deployed to. A remote repository must first be defined with that ID in BuildConfig.groovy.
  • protocol specifies the protocol to use when deploying the plugin to a Maven-compatible repository. Can be one of 'http', 'scp', 'scpexe', 'ftp', or 'webdav'. The default is 'http'.
  • portal specifies the ID of the portal to notify. For this to work, a portal must be configured for that ID in BuildConfig.groovy.
  • pingOnly forces the command to only notify the configured portal - the plugin is not published to a repository.
  • scm enables source control management for this release. It is on by default unless disabled via the grails.release.scm.enabled configuration setting.
  • noScm disables source control management for this release.
  • binary packages the plugin in binary form before publishing it. This overrides the default packaging for the plugin.
  • no-overwrite ensures the script exits with a status of 0 if this plugin has already been published. This is useful if this plugin is being published from a continuous integration server and you don't want the command to exit with failure.
  • allow-overwrite writes over any existing plugin with the same name and version number

Examples

Publish to the Grails Central Plugin Repository and notify the grails.org plugin portal of the release:

grails publish-plugin

Publish to the repository 'myRepo' - whatever portal (if any) is configured for that repository will be notified by the command:

grails publish-plugin --repository=myRepo

Publish to the custom repository 'acme', notify the plugin portal declared with the ID 'comp', and force this release to be treated as a snapshot:

grails publish-plugin --repository=acme --portal=comp --snapshot

Description

In order for Grails to use plugins declaratively via the dependency DSL, they must be published to a repository. This command allows you to publish to both Maven-compatible and old-style Subversion repositories while also optionally notifying a plugin portal (like the one on grails.org) of the plugin releases.

When publishing a public plugin, i.e. one that is hosted on the Grails Central Plugin Repository and the grails.org plugin portal, this command is typically run as:

grails publish-plugin

You may end up in the situation where the plugin has been deployed to its repository but the portal wasn't notified, for example if the portal is unavailable when you execute the command. In this case, you can attempt to notify the plugin portal at a later date by using the --pingOnly option, which bypasses the plugin deployment.

Events

  • PublishPluginStart - Fired when the publish plugin command starts. One argument is passed in the event: a plugin info object with name, version, group, and isSnapshot properties.
  • DeployPluginStart - Fired just before the plugin is deployed to its repository. Takes three arguments: a plugin info object (see PublishPluginStart), the location of the plugin zip, and the location of the POM file.
  • DeployPluginEnd - Fired just after the plugin is deployed to its repository. Takes three arguments: a plugin info object (see PublishPluginStart), the location of the plugin zip, and the location of the POM file.
  • PingPortalStart - Fired just before the plugin portal is notified. Takes three arguments: a plugin info object (see PublishPluginStart), the URL of the plugin portal, and the URL of the repository to which the plugin was deployed.
  • PingPortalEnd - Fired just after the plugin portal is notified. Takes three arguments: a plugin info object (see PublishPluginStart), the URL of the plugin portal, and the URL of the repository to which the plugin was deployed.
  • PublishPluginEnd - Fired at the end of the command. Has one argument: a plugin info object (see PublishPluginStart).

In the plugin info object, name is the name of the plugin, version is its version number, group is the group ID that goes in the POM, and isSnapshot indicates whether the plugin is a snapshot version (true) or not (false).