The fifth installment on the Griffon 0.9 sneak peek series is about the framework's infrastructure, where the most radical change is the location of the buildtime configuration, so let's start with that one.

1. Configuration

Early releases of Griffon would let you specify buildtime configuration in a single file: griffon-app/conf/Config.groovy. In a more recent release another file was added: griffon-app/conf/BuildSettings.groovy. Unfortunately many developers mistakenly thought that any configuration set in Config.groovy was available at runtime, and not many knew about the existence of BuildSettings.groovy. Starting with this release there's a new way to work with configuration files:

• Application.groovy - remains as the source for MVC group configuration. No other configuration flags should be set on this file, however this rule is not actively enforced by the build system.
• Builder.groovy - still the place to configure all builder contributions, no changes here.
• BuildConfig.groovy - formerly known as BuildSettings.groovy, this file contains all packaging and deployment configuration. This is also the place where plugins will look for data they might require during script execution.
• Config.groovy - promoted to runtime. This file should contain all other runtime configuration that does not belong in Application.groovy, for example GSQL's inject rules.

You might be wondering, if Config.groovy is now of runtime status, how would an application get access to the configuration set on it? Well, applications already had a config property that holds whatever information is available in Application.groovy. Now that property holds the merged data from Application.groovy and Config.groovy. So in the end, an application needs no changes at runtime to read all of its configuration.

An additional tweak for BuildConfig.groovy is available too. This file holds the buildtime configuration for a single application, so you can't share it with another application unless you copy and paste the contents. Well it turns out there's another option. Buildtime configuration that is to be shared across applications can be placed at $USER_HOME/.griffon/settings.groovy. This is the same way buildtime configuration works in Grails.

2. Groovy support

Griffon 0.9 comes with the latest Groovy 1.7.3. Enuff' said

3. Build event order

In the past, build event handlers provided by plugins would be executed in the order they were found: alphabetically. This means that if plugin A depends on B, script A depends on script B and it requires events from B to be handled before... you were out of luck. Well not anymore, the build system now uses a new approach. It will still look for events in alphabetical order, but it will immediately rearrange the execution order as soon as it encounters a plugin with a dependency on another plugin.

4. Project documentation engine

Another feature stemming from Grails 1.3.x. It is now possible on application and plugin projects to run the same documentation engine that powers the Griffon Guide.

Keep on Groovying!