Griffon is most definitely an opinionated framework and it prefers convention to configuration, but this doesn't mean you can't configure it. In this section, we look at how you can influence and modify the standard Griffon build.

The defaults

In order to customize a build, you first need to know what you can customize. The core of the Griffon build configuration is the griffon.util.BuildSettings class, which contains quite a bit of useful information. It controls where classes are compiled to, what dependencies the application has, and other such settings.

Here is a selection of the configuration options and their default values:
PropertyConfig optionDefault value
griffonWorkDirgriffon.work.dir$USER_HOME/.griffon/<griffonVersion>
projectWorkDirgriffon.project.work.dir<griffonWorkDir>/projects/<baseDirName>
classesDirgriffon.project.class.dir<projectWorkDir>/classes
testClassesDirgriffon.project.test.class.dir<projectWorkDir>/test-classes
testReportsDirgriffon.project.test.reports.dir<projectWorkDir>/test/reports
resourcesDirgriffon.project.resource.dir<projectWorkDir>/resources
projectPluginsDirgriffon.plugins.dir<projectWorkDir>/plugins

The BuildSettings class has some other properties too, but they should be treated as read-only:
PropertyDescription
baseDirThe location of the project.
userHomeThe user's home directory.
griffonHomeThe location of the Griffon installation in use (may be null).
griffonVersionThe version of Griffon being used by the project.
griffonEnvThe current Griffon environment.
compileDependenciesA list of compile-time project dependencies as File instances.
testDependenciesA list of test-time project dependencies as File instances.
runtimeDependenciesA list of runtime-time project dependencies as File instances.

Of course, these properties aren't much good if you can't get hold of them. Fortunately that's easy to do: an instance of BuildSettings is available to your scripts via the griffonSettings script variable. You can also access it from your code by using the griffon.util.BuildSettingsHolder class, but this isn't recommended.

Overriding the defaults

All of the properties in the first table can be overridden by a system property or a configuration option - simply use the "config option" name. For example, to change the project working directory, you could either run this command:

griffon -Dgriffon.project.work.dir=work compile
or add this option to your griffon-app/conf/BuildConfig.groovy file:
griffon.project.work.dir = "work"
Note that the default values take account of the property values they depend on, so setting the project working directory like this would also relocate the compiled classes, test classes, resources, and plugins.

What happens if you use both a system property and a configuration option? Then the system property wins because it takes precedence over the BuildConfig.groovy file, which in turn takes precedence over the default values.

Available build settings

NameDescription
griffon.compiler.dependenciesLegacy approach to adding extra dependencies to the compiler classpath. Set it to a closure containing "fileset()" entries.
griffon.testing.patternsA list of Ant path patterns that allow you to control which files are included in the tests. The patterns should not include the test case suffix, which is set by the next property.
griffon.testing.nameSuffixBy default, tests are assumed to have a suffix of "Tests". You can change it to anything you like but setting this option. For example, another common suffix is "Test".