(Quick Reference)
4.4 Customising the build - Reference Documentation
Authors: Andres Almiray
Version: 1.2.0
4.4 Customising the build
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:
Property | Config option | Default value |
---|
griffonWorkDir | griffon.work.dir | $USER_HOME/.griffon/<griffonVersion> |
projectWorkDir | griffon.project.work.dir | <griffonWorkDir>/projects/<baseDirName> |
classesDir | griffon.project.class.dir | <projectWorkDir>/classes |
testClassesDir | griffon.project.test.class.dir | <projectWorkDir>/test-classes |
testReportsDir | griffon.project.test.reports.dir | <projectWorkDir>/test/reports |
resourcesDir | griffon.project.resource.dir | <projectWorkDir>/resources |
projectPluginsDir | griffon.plugins.dir | <projectWorkDir>/plugins |
The
BuildSettings
class has some other properties too, but they should be treated as read-only:
Property | Description |
---|
baseDir | The location of the project. |
userHome | The user's home directory. |
griffonHome | The location of the Griffon installation in use (may be null). |
griffonVersion | The version of Griffon being used by the project. |
griffonEnv | The current Griffon environment. |
compileDependencies | A list of compile-time project dependencies as File instances. |
testDependencies | A list of test-time project dependencies as File instances. |
runtimeDependencies | A 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
Name | Description |
---|
griffon.testing.patterns | A 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. |
Additional Sources
The Griffon build automatically compiles all Java & Groovy sources found under
src/main
. Follow these steps should you require additional sources to be compiled during the same compilation step
- Create a file named
_Events.groovy
under the scripts
directory.
- Create a build event handler that configures the new path. The handler must react to a particular build event. Either
CompileStart
or CompileSourcesStart
will do the trick.
eventCompileSourcesStart = {
[
'src/legacy', // relative path
new File('/development/projects/sample/src').canonicalPath // absolute path
].each { dir ->
if (!(dir in additionalSources)) additionalSources << dir
}
}
Note that you can define relative and absolute paths. This tip works in both plugin and application projects.