(Quick Reference)

4.7 Command Line Options - Reference Documentation

Authors: Andres Almiray

Version: 1.2.0

4.7 Command Line Options

The following command line options only have meaning while building the project. They have no effect when running the application once it has been packaged.

It's worth noting that all of the following options can also be specified in either griffon-app/conf/BuildConfig.groovy (local to project) or $USER_HOME/.griffon/settings.groovy (global to all projects), with the caveat that values specified at the command prompt will have precedence over those specified in the config file.

4.7.1 Offline Mode

Most of the times invoking the Griffon command requires a network connection open in order to resolve dependencies. There are times when network access is not available. It's possible to instruct the command line to avoid performing network checks whenever the network is down or unavailable. this is done by activating offline mode. Simply set the following flag: griffon.offline.mode.

For example, compiling an application in offline mode is done by invoking

griffon -Dgriffon.offline.mode=true compile

It's worth noting that all dependencies and plugins should be able to be resolved using the local dependency cache and any configured local artifact repositories. If any of such dependencies fails to be resolved then it's very likely that the command will fail to perform its job.

4.7.2 Verbose Output

Scripts have the choice of printing to the console whenever they need to communicate something to the developer. They would normally use a standard println sentence. Sometimes it's useful to know what a script is doing with further detail but it makes no sense to see that information every single time. A conditional output is required.

All scripts inherit a debug() closure that will print its argument to stdout if an only if the following flag is enabled: griffon.cli.verbose. As an example, the following script has two print outs

// Include core griffon scripts with the following call
//
//     includeTargets << griffonScript('_GriffonCompile')
//
// Include plugin scripts with the following call
//
//    includeTargets << griffonPluginScript('some-plugin-name', 'ScriptName')
//

target(name: 'hello', description: "The description of the script goes here!", prehook: null, posthook: null) { println 'Hello world!' debug 'Hello World (debug)' } setDefaultTarget('hello')

Running the script without the flag will print out 'Hello World!' all the time but never the second one

$ griffon hello
Welcome to Griffon 1.2.0 - http://griffon-framework.org/
Licensed under Apache Standard License 2.0
Griffon home is set to: /usr/local/griffon
…
Environment set to development
Hello world!

The second message will only appear if you specify the verbose flag

$ griffon -Dgriffon.cli.verbose=true hello
Welcome to Griffon 1.2.0 - http://griffon-framework.org/
Licensed under Apache Standard License 2.0
Griffon home is set to: /usr/local/griffon
…
Environment set to development
Hello world!
[5/15/12 11:39:12 AM] Hello World (debug)

4.7.3 Disable AST Injection

Since Griffon 0.9.1 all artifacts now share a common interface (GriffonArtifact). They may implement additional interfaces that define their role in a better way. For example controllers implement GriffonController whereas models implement GriffonModel. Despite this, you are not forced to implement these interfaces yourself, the Griffon compiler can do the work for you. It will even inject the appropriate behavior to classes that extend from base types other than Object. All this is done by leveraging the powerful AST Transformations framework introduced in Groovy 1.6.

If this feature ever gets in the way then you can disable it with the following command flag

griffon -Dgriffon.disable.ast.injection=true compile

Be sure to clean the project before using this flag, otherwise some classes may still have the AST additions weaved into their bytecode.

4.7.4 Disable Default Imports

Another feature introduced in Griffon 0.9.1 is the ability to define default imports for artifacts and scripts.

If this feature proves to be a disadvantage then disable it with the following command flag

griffon -Dgriffon.disable.default.imports=true compile

4.7.5 Disable Conditional Logging Injection

Griffon 0.9.1 added a log property to all artifacts, and enabled logging on addons. Groovy 1.8 adds a new set of AST transformations, @Log being one of them. It's job is to transform an unguarded logging statement into a guarded one. Starting with 0.9.2, Griffon can do the same without the need of annotating artifacts or addons with @Log.

If this feature proves to be a disadvantage then disable it with the following command flag

griffon -Dgriffon.disable.logging.injection=true compile

4.7.6 Disable Threading Injection

Griffon 0.9.2 adds the option for all controller actions to be executed off the UI thread automatically. This feature breaks backward compatibility with previous releases.

In order to regain the previous behavior you can disable this feature by specifying the following command flag

griffon -Dgriffon.disable.threading.injection=true compile

4.7.7 Default Answer in Non Interactive Mode

Sometimes a command may require the user to specify a missing value. When the build is run in interactive mode (the default mode) then it's just a matter of typing the value in the console. However, if the build is run in non-interactive mode then it's very likely it will fail.

For this reason, the Griffon build accepts the definition of a default answer if the griffon.noninteractive.default.answer key is specified, like this

griffon -Dgriffon.noninteractive.default.answer=y release-plugin

Be warned that this setting applies to every single input asked by a command.

4.7.8 Force Artifact Upgrades

Griffon follows a convention for version numbers when applied to artifacts (such as plugins and archetypes). This convention splits the version number into the following parts

<major>.<minor>.<revision>-<tag>

where revision and tag may be omitted. When artifacts get upgraded Griffon will check for number compatibility and pick the version whose numbers are greatest than the rest. However in the case of major it will throw an error if two version numbers differ, as the convention is that there's bound to be a compatibility conflict if there are at least two different values for major .

Developers can inspect the conflicts report and consult the release notes for each marked dependency and decide if the upgrade should proceed or not. If the decision is to continue with the upgrade then the developer must inform the build that a forced upgrade must occur. This can be accomplished by setting the griffon.artifact.force.upgrade flag to true, like this

griffon -Dgriffon.artifact.force.upgrade=true clean

Both install-plugin and install-archetype commands have a shortcut option (force-upgrade) that can set the value of this flag. Here's an example report showing two different versions of the swing plugin

! swing-1.1.0 from griffon-local
! glazedlists-0.9 from griffon-local
   ! swing-0.9.5 from griffon-local
Could not resolve plugin dependencies.

The character ! next to each artifact name/version means there's a conflict in that artifact or any of its dependencies. Additional characters may be present (one per line)

  • . the artifact is installed
  • + the artifact will be installed
  • - the artifact will be removed
  • ? the artifact could not be resolved

For example, adding a plugin dependency on bogus-0.0.0 results in the following output

-= INSTALLED =-
. glazedlists-0.9
   . swing-1.1.0
. swing-1.1.0
-= MISSING =-
? bogus-0.0.0 not found in any repository

4.7.9 Plugin Install Failure Strategies

Failures may occur during plugin installation. It may be the case that a plugin could not be found in the configured repositories, or a JAR dependency failed to be resolved. When this happens the build will try its best to cope with the error, usually by continuing installing remaining plugin dependencies (if any).

This behavior can be altered by specifying a value for griffon.install.failure. Accepted values are:

ValueDescription
abortAborts the installation sequence, even if there are other plugins left to be installed. It will also delete all installed plugins in the current session. This is the old behavior prior to Griffon 0.9.5.
continueContinues with the next plugin in the list. This is the default behavior.
retryRetries failed plugins a second time. A second failure skips the plugin from being installed but does not affect any other plugins that have been successfully installed or are yet to be installed.

For example, to return the build to its previous behavior (abort on failures) you'll type the following in your command prompt

griffon -Dgriffon.install.failure='abort' compile

4.7.10 Default Artifact Repository for Searching

The Griffon build assumes griffon-central to be the default Artifact Repository to be searched when querying for artifacts (either to list them, get some info or install them). This setting can be altered by specifying a value for griffon.artifact.repository.default.search. The value must be a valid repository name available in the configuration files.

For example, a local repository identified by the name 'my-local-repo' can be set as the default search repository like so

griffon -Dgriffon.artifact.repository.default.search='my-local-repo' install-plugin cool-plugin

4.7.11 Default Artifact Repository for Caching

When a plugin or archetype is downloaded from an artifact repository the Griffon build will place a copy of it in the griffon-local repository. This speeds up searches and further plugin installations. If you would like to specify a different local repository to be used as a cache then define a value for the griffon.artifact.repository.default.install key.

Assuming that 'my-local-repo' is configured in the project's settings then the following command will download the miglayout plugin and place a copy in that specific repository.

griffon -Dgriffon.artifact.repository.default.install='my-local-repo' install-plugin miglayout

4.7.12 Default Artifact Repository for Publishing

The Griffon build assumes griffon-central to be the default Artifact Repository to be used when releasing artifacts. This setting can be altered by specifying a value for griffon.artifact.repository.default.release. The value must be a valid repository name available in the configuration files.

For example, a local repository identified by the name 'my-local-repo' can be set as the default publish repository like so

griffon -Dgriffon.artifact.repository.default.release='my-local-repo' release-plugin

Note that specifying this value at the command line has the same effect as defining a value for --repository. This flag is best used in any of the configuration files available at build time.

4.7.13 Disable Automatic Local Repository Synchronization

Section 4.7.9 describes that copies of plugins and archetypes will be placed in a local repository whenever they are downloaded from other repositories. You can disable this feature altogether by specifying a value for griffon.disable.local.repository.sync as true, like the following example shows

griffon -Dgriffon.disable.local.repository.sync=true install-archetype scala