3 Configuration

It is suggested that you keep at least the username and password in your ~/.grails/settings.groovy file so that it is not tied to your project source code. This is a safer location, expecially if your source code is shared with others, or is an open source project.

Defaults

The defaults settings should be enough to get most people up and running. These are the settings that are used when the deployer command is called without any arguments.

The following settings should be prefaced by: grails.plugins.deploy.defaults. For example the containerId setting would become grails.plugins.deploy.defaults.containerId

containerId

This must match the containerId of your servlet container from the list provided on the cargo site. The default containerId is 'tomcat7x'

containerType

One of 'remote', 'installed' or 'embedded'. See the class definition for details.

deployerType

One of 'remote', 'installed' or 'embedded'. See the class definition for details.

configurationType

One of 'runtime', 'existing' or 'standalone'. See the class definition for details.

The use of anything other than 'runtime' is not recommended unless you know what you are doing.

propertySet

This is a map containing the cargo configuration properties that are used to connect to the container and deploy or control the WAR file or application.

Some common settings would look like

grails.plugins.deploy.defaults.propertySet = [
			'remote.username': 'autodeployer',
			'remote.password': 'UGheoqu0Washu2aa0Li1',
			protocol: 'http',
			hostname: 'localhost',
			'servlet.port': 8080 ]

For a complete list of properties, see the cargo containt values page. An alternate listing is available on the properties page

Destinations

To manage configurations for more than one destination, you can set up a map containing destiniation specific settings. This is useful for setting up a different configuration for testing vs. staging vs. production. You can also set up configurations for multiple servers if you deploy your app to multiple production servers either for load balancing, or for geographical reasons.

You only need to set the options that are different than those set in your grails.plugins.deploy.defaults setting. This will keep the size of your destinations settings down.

An example configuration for a few different destinations would look like

grails.plugins.deploy.destinations = [
	// staging deploy destination
	staging: [
		propertySet: [
			protocol: 'https',
			hostname: 'testing.example.org',
			'servlet.port': 8443 ] ],
	// production deploy destination
	production: [
		propertySet: [
			protocol: 'https',
			hostname: 'www.example.org',
			'servlet.port': 443 ] ],
	// local test server destination
	testing: [
		containerId: 'tomcat6x',
		propertySet: [
			'remote.username': 'deployer',
			'hostname': '192.168.6.142',
			'servlet.port': 80 ] ] ]

Groups

The grails.plugins.deploy.groups setting lets you set up different groups you can use to deploy your application WAR file to. The following example sets up an east coast and a west coast group. These group names will then be passed to the --destination-group command line parameter.

grails.plugins.deploy.groups = [ 
	westCoast: [ 'seattle', 'sandiego' ],
	eastCoast: [ 'maryland', 'newyork'] ]

Each of the destinations above would also need to have a corresponding entry in the grails.plugins.deploy.destinations configuration option. For example:

grails.plugins.deploy.destinations = [
	…
	seattle: [
		propertySet: [ hostname: 'app-seattle.example.org' ]
   …
   ]