Native Libraries Support

Starting with this release you'll be able to place platform specific jars and lib files (.dll, .so, etc) on specific places and the framework will take care of the rest. The following platforms are supported at the moment: linux, windows, macosx, solaris (all 32bit versions). Follow the next convention to take advantage of this feature:

1. create a dir inside $basedir/lib with a platform name, for example linux.

2. place all linux specific jars on that directory.

3. if native files are required then create a native subdir in lib/linux and place the files inside there.

You may configure as many of the supported platforms but only the current one (where you're developing on) will be used when running the application on development mode. Packaging the application however, will gather all platforms together. You may configure additional settings per platform when running on applet/webstart. See the following section.

Packaging

Tweaking the generated JNLP and applet HTML files is now possible via configuration, opening the door for platform specific updates and plugins alike. This release includes a new section on Config.groovy, reproduced here for your convenience

Each key/value pair on the props node will be mapped to a <property> under the general <resources> tag. The resources node only accepts children whose name match the supported platforms (as suggested on the snippet. Both jars and nativelibs must contain a list of jar archives (either relative or absolute), as per the JNLP file syntax. Notice that you can also set platform specific properties.

Applet parameters may be specified as well, they will be set on the applet's JNLP and HTML files.

Finally you can change the default width (240) and height (320) of the applet container during packaging by passing -appletWidth and -appletHeight flags to the griffon command.

Help

Continuing what was started on the 0.2.x series this release provides better descriptions when the help command is invoked on a core command. Additionally plugin scripts will also be available to the help command. A note to plugin authors: make sure to provide a suitable description for the default target on your scripts, this way the help command will be able to present it to the user.

Stats

The stats command can now generate additional output in 3 formats: text, html and xml. Specify any of [-txt, -html, -xml] when invoking the command to get the desired output. The output files will be placed at config.griffon.testing.reports.destDir or $basedir/target if the former is not specified.

Docs

It is now possible to skip the generation of docs while packaging. This is useful while doing plugin development as it cuts the time of packaging the plugin. Use the -nodoc flag on the command line.

Artifacts API

The Artifacts API fills the need to determine what type of artifact an instance may be. Base artifacts are: Model, View, Controller and Service. All artifact metadata is available through the ArtifactManager, a convenient artifactManager property is added to all application instances. ArtifactManager provides methods to evaluate the conventions within the project and stores internally references to all classes within a GriffonApplication using the ArtifactInfo class. An ArtifactInfo represents a physical Griffon resource such as a controller or a service. For example to get all ArtifactInfo instances you can do:

There are a few "magic" properties that the ArtifactManager instance possesses that allow you to narrow the type of artifact you are interested in. For example if you only want to print the name of all controller artifacts you can do:

The dynamic method conventions are as follows:

• *Artifacts - Retrieves all the artifacts for a particular artifact type. Example app.artifactManager.controllerArtifacts.
• get*Artifact() - Retrieves a named artifact for a particular artifact type. Example app.artifactManager.getControllerArtifact("ExampleController")
• is*Artifact() - Returns true if the given class is of the given artifact type. Example app.artifactManager.isControllerArtifact(ExampleController)
• *Classes - Retrieves all the classes for a particular artifact type. Example app.artifactManager.controllerClasses.
• is*Class() - Returns true if the given class is of the given artifact type. Example app.artifactManager.isControllerClass(ExampleController)

The ArtifactInfo interface itself provides a number of useful methods that allow you to further evaluate and work with the conventions. These include:

• newInstance() - Creates a new instance of this class.
• getName() - Returns the logical name of the class in the application without the trailing convention part if applicable
• getSimpleName() - Returns the name of the class as a property name
• geKlass() - Returns the artifact class
• geDynamicProperties() - Returns a List of all properties that have been added dynamically to this artifact's klass, usually added by metaClass.
• geAllProperties() - Returns a List of all properties related to this artifact's klass, excluding [class, metaClass].

Services

Services support is now provided from the get go. There is a new command, create-service, that creates a new service artifact following a simple template, it will also create a test for it. Services are injected automatically into other artifacts by following a naming convention.

Dependency Injection While services will be injected by matching property names this doesn't mean Griffon sports a Dependency Injection solution on the core, you would need to install a plugin that does that. Fortunately there are a few options already: Guice and Spring.

Addons

The addon template now contains hints to all configurable options. Missing from the previous release were the FactorBuilderSupport delegates: attributeDelegate, preInstantiateDelegate, postInstantiateDelegate and postNodeCompletionDelegate.

There are 4 new application events related to addon initialization: global and local:

Global

• LoadAddonsStart[app] - triggered before any addon is initialized
• LoadAddonsEnd[app, addons] - triggered after all addons have been initialized. addons is a Map of <name, instance> pairs

Local

• LoadAddonStart[name, addon, app] - triggered before an addon is initialized
• LoadAddonEnd[name, addon, app] - triggered after the addon has been initialized

Threading

A new threading abstraction is available: griffon.util.UIThreadHelper. This class provides equivalent functionality as SwingBuilder's edt, doLater and doOutside; however it is not tied to Swing, which makes supporting other toolkits like SWT, Pivot and Gtk a reality. This also frees you from instantiating SwingBuilder, or keeping a reference to it, in order to take advantage of its threading features. UIThreadHelper is a singleton class, accessible from anywhere at any time. This is its contract for reference

Inspection

An application is now able to know in which mode (environment) it is running by querying griffon.util.Environment.getCurrent(). Similarly the application's metadata (or application.properties) is now accessible via griffon.util.Metadata.getCurrent().

Deprecations

griffon.util.IGriffonApplication -> griffon.core.GriffonApplication

griffon.util.GriffonApplicationHelper.invokeScriptInsideEDT -> griffon.util.GriffonApplicationHelper.invokeScriptInsideUIThread