Overview

Griffon 0.9.3 – "Aquila morphnoides" - is a maintenance release of Griffon 0.9.

New Features

Buildtime

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

application.icon = '/application-relative/path/to/file.icns'

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

griffon create-service -service=MyService

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

griffon create-mvc -view=CustomView

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

griffon create-mvc foo -group=Custom

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.

griffon create-mvc foo -skipController=true

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

mvcGroups {
    // MVC Group for "foo"
    'foo' {
        model      = 'foo.FooModel'
        view       = 'foo.FooView'
    }
    ...
}

griffon create-mvc foo -withController=foor.BarController

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

mvcGroups {
    // MVC Group for "foo"
    'foo' {
        model      = 'foo.FooModel'
        view       = 'foo.FooView'
        controller = 'bar.BarController'
    }
    ...
}

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

griffon create-app sample -archetype=jumpstart

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

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.1
Created-By: ${jvm.version} (${jvm.vendor})
Main-Class: ${griffonApplicationClass} | ${griffonAppletClass}
Built-By: ${user.name}
Build-Date: dd-MM-yyyy HH:mm:ss
Griffon-Version: ${griffonVersion}
Implementation-Title: capitalize(${griffonAppName})
Implementation-Version: ${appVersion}
Implementation-Vendor: capitalize(${griffonAppName})

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

griffon {
    jars {
        manifest = [
            'Foo': 'Bar'
            'Built-By': 'Acme'
        ]
    }
}

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

griffon {
    jars {
        merge = [
            '.*.xml': org.codehaus.griffon.ant.taskdefs.FileMergeTask.Replace
        ]
    }
}

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.

Runtime

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

griffon -Dfoo=foo -Dbar=bar run-app

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

log4j = {
    appenders {
        console name: 'stdout', layout: pattern(conversionPattern: '%d [%t] %-5p %c - %m%n')
        event   name: 'redirect', layout: pattern(conversionPattern: '%d [%t] %-5p %c - %m%n')
    }
    ...
}

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

withMVCGroup('display') { m, v, c ->
    m.title = 'Information'
    m.message = 'Something cool is about to happen'
    c.show()
}

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:

platform {
    handler = [
        macosx: 'com.acme.MyMacOSXPlatformHandler'
    ]
}

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

package com.acme

import griffon.core.GriffonApplication
import griffon.util.PlatformHandler

class MyMacOSXPlatformHandler implements PlatformHandler {
    void handle(GriffonApplication app) {
        System.setProperty('apple.laf.useScreenMenuBar', 'true')
        ...
    }
}

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.

Breaking Changes

Runtime Behavior

All of the createMVCGroup, buildMVCGroup and withMVCGroup methods have been moved from the griffon.core.GriffonMvcArtifact interface to the griffon.core.GriffonArtifact interface.
The signature of mvcGroupInit(Map<String, ?>) has been changed to mvcGroupInit(Map<String, Object>).

All AST xforms have been relocated to package griffon.transform to align them with Groovy 1.8.0 where most are now found in groovy.transform; this results in the following changes

• griffon.beans.Listener -> griffon.transform.PropertyListener
• griffon.util.EventPublisher -> griffon.transform.EventPublisher
• griffon.util.Threading -> griffon.transform.Threading

The package griffon.transform is not auto imported by default. Usage of these AST transformations must be declared explicitly.

Both griffon.core.GriffonApplication and griffon.core.GriffonArtifact now extend griffon.core.MVCHandler and griffon.core.ThreadingHandler.

The interface griffon.util.EventPublisher is no longer an AST transformations (because it was relocated), it now identifies a class that can publish events using an EventRouter.

griffon.util.EventRouter moved to org.codehaus.griffon.runtime.core.EventRouter

griffon.util.UIThreadHelper moved to griffon.core.UIThreadManager

Dependencies

New versions for the following dependencies

• Groovy 1.8.1
• Gant 1.9.6

Sample Applications

Griffon 0.9.3 ships with 5 sample applications of varying levels of complexity demonstrating various parts of the framework. In order of complexity they are:

File Viewer

File Viewer is a simple demonstration of creating new MVCGroups on the fly.

Source: samples/FileViewer

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

GroovyEdit

GroovyEdit is an improved version of FileViewer that uses custom observable models.

Source: samples/GroovyEdit

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

Font Picker

Font Picker demonstrates form based data binding to adjust the sample rendering of system fonts.

Source: samples/FontPicker

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

Greet

Greet, a full featured Griffon Application, is a Twitter client. It shows Joint Java/Groovy compilation, richer MVCGroup interactions, and network service based data delivery.

Source: samples/Greet

To run the sample from source, change into the source directory and run griffon run-webstart from the command prompt. Because Greet uses JNLP APIs for browser integration using run-app will prevent web links from working.

SwingPad

SwingPad, a full featured Griffon Application, is a scripting console for rendering Groovy SwingBuilder views.

Source: samples/SwingPad

To run the sample from source, change into the source directory and run griffon run-app from the command prompt.

0.9.3 Release Notes

0.9.3-beta-1 Release Notes

0.9.3-beta-2 Release Notes