Dependencies

Griffon 0.9.3 relies on Groovy 1.8.1 and Gant-groovy-1.8 19.6. This means code compiled with previous versions of Groovy might not work immediately out of the box. The reason being that Groovy 1.7 and 1.8 are not entirely binary compatible. Griffon 0.9.3 includes a temporary workaround. It's perfectly safe to recompile your code with this release.

Change dock icon in OSX

RunApp now assumes there is a <applicationFile>.icns file located at griffon-app/conf/dist/shared.

This setting can be overridden by defining a configuration flag in griffon-app/conf/BuildConfig.groovy

If neither of these two settings is available then the default icon ( griffon.icns) will be used

Jumpstart archetype improvements

The jumpstart archetype code has been streamlined with the addition of the Actions Plugin. Now all actions are automatically configured via resources, which reduces the amount of code to set them up. Also, Java based templates have been added.

Templates

Almost every create-* script relies on a template in order to create the desired artifact. This template could only be overridden if a plugin (or the application) provided another template that matched the same name as the original one. Clearly that is not an scaling solution so the template system has been revamped to accept a different template depending on the options specified during the command invocation. For example, creating a service with a custom template named MyService you would now invoke the following command

Basically you specify the type of the artifact as an option (using lowercase on the first char), which leads to the following cases to be valid too

Speaking of MVC groups, the create-mvc command has additional settings that can be configured, like this

Creates a new group definition where MVC member templates are assumed to be CustomModel, CustomView and CustomController. Will use the default template when there's no match.

Creates a new group definition without a Controller. The configuration will look like this

Creates a new group definition with another Controller class. The Controller is assumed to exist, a file will not be created for it. The configuration will look like this

Application Archetypes

Theres a new application archetype available. It bootstraps an application in a similar way as Ubuntu's Quickly does. Here's how to use it

The generated code is fully i18n aware and customizable.

Default Package Name

When an application is created it will attempt to use the name of the application as the default package name for the initial MVC group (unless -skipPackagePrompt is specified). This package name is now stored in griffon-app/conf/BuildConfig.groovy for future references by additional scripts.

Filter Plugins by Platform

Calling griffon list-plugins will now filter the list automatically, leaving out those plugins that do not match the current development platform you're working on.

IDE Support

It's been a while since IDEA added support for Groovy DSL descriptors. Recently Eclipse gained the same capabilities via DSLD ( explained by Andrew Eisenberg, Vladimír Oraný posted a thorough tutorial here). During Gr8conf Copenhagen 2010 a group of Griffon enthusiasts banded together under the Hackergarten space and created a couple of GDSLs specifically tailored for Griffon. This year was no different, a similar group managed to build improved versions of these GDSLs plus the first cur of DSLDs. These scripts should be automatically picked up by either IDE as soon as the Griffon jars are placed in the classpath. So what exactly do you gain now?

• autocompletion of Swing nodes when working in a Griffon View script.
• autocompletion of methods from standard Griffon artifacts.
• autocompletion of methods from the following AST transformations: @Bindable, @Vetoable, @EventPublisher, @MVCAware, @ThreadingAware

Configure Application's Manifest

It's now possible to configure the manifest that's placed inside the application's jar. Griffon will automatically create the following entries in the application's manifest

There might be times when you must specify additional attributes or override existing ones. You can do this by adding a new block of configuration to BuildConfig.groovy, for example

Merge duplicate files when packaging

There's a high chance of some files to have duplicates, e.g. griffon-artifacts.properties if you have installed a plugin that provides MVC groups. It's possible to instruct the build to merge duplicate files by specifying a regular expression and a merging strategy. The following table explains the different merging strategies available

You can specify merging preferences in @BuildConfig.groovy@ like this

This setting will overwrite any XML file found in the path with the last version encountered as jars are processed.

The griffon build defines a set of default mappings, which are the ones found in the next table

Merging preferences must be defined from the most specific to the least. Your preferences will override any default settings.

Creating and MVC group with the same mvcName

The value of the mvcName parameter must be unique otherwise a collision will occur. When that happens the application will report and exception and terminate. This behavior can be configured to be more lenient, by defining a configuration flag griffon.mvcid.collision in Config.groovy.

Accepted values are

• warning - reports the error but allows the application to continue. Destroys the existing group before continuing.
• exception - reports the error and terminates the application. this is the default behavior.

Set multiple System props on the command line

It's now possible to define multiple System properties on the command line when invoking run-app for example. These properties will be directly available when you call System.getProperty(somePropertyName). Here's a sample invocation with two parameters

Event Aware Logging Appender

There's a new application event aware logging appender that can fire events whenever a logging statement is received. Here's how it can be configured in griffon-app/conf/Config.groovy

This appender triggers an event named "LogEvent" which takes 3 arguments: the logging level (as a String), the logging message and an optional throwable.

Short-lived MVC groups

There are times when an MVC group instance must be created and discarded shortly afterwards. Griffon already sports a simple MVC lifecycle however it's easy to miss it which can lead to memory leaks. This is why a new set of methods have been added to both application and artifact interfaces. Say for example you want to create a modal dialog that is backed by an MVC group named 'display'. The model of this dialog has a title and message properties that are used to customize its looks. Heres' how it can be used with the new construct

This code assumes the controller of this group also has an action named show. The group will be automatically destroyed once the dialog is dismissed or closed.

Automatic Registration of ArtifactHandlers

In the past plugin authors were required to initialize and register their custom ArtifactHandlers during the addon init step. This is no longer the case as long as the full qualified class name of the ArtifactHandler is placed in the following file griffon-app/conf/metainf/services/griffon.core.ArtifactHandler.

Configurable Platform Customizations

In the past, platform customizations like the handling of the About and Preferences menu in OSX, were handled internally by the Griffon runtime, giving you no chance to override or alter the default behavior. That has been changed now. Starting with this release you should be able to instruct the runtime how you want those customizations to be applied. You only need to implement the griffon.util.PlatformHandler interface and register your implementation. The following configuration in Config.groovy specifies a different handler for macosx:

Now you only need to create such handler, like this:

The following platform keys are recognized by the application in order to locate a particular handler: linux, macosx, solaris and windows.

New AST Transformations

It's possible for non-artifact classes to participate in the MVC group mechanism (but not he life cycle itself) by implementing the griffon.core.MVCHandler interface. This task is easily achieved by annotating the class with griffon.transform.MVCAware. The same can be said for classes that would like to gain the capabilities of executing code using the threading facilities exposed by Griffon. The interface is griffon.core.ThreadingHandler and the transformation is griffon.transform.ThreadingAware.

0.9.3 Release Notes

0.9.3-beta-1 Release Notes

0.9.3-beta-2 Release Notes