Happy Birthday Griffon! I can't believe it's been 3 years since Danno posted the first announcement. Griffon has come a looong way since. We started the project with the goal of making a framework that would deliver the same productivity gains on the desktop area as Grails did on the web. I don't think we understood the implications of such goal at the time, however I'm quite happy with the results so far. We're really close to achieving the goal we set forward since the beginning.

During the last year the framework has received plenty of feedback from many sources. The team welcomed two new members that injected new life and new perspectives. The code itself has grown and shrunk a couple of times, and yet we keep adding interesting features to it. The plugin community is also building up. In particular I'd like to thank Nick Zhu for his heoric efforts in porting Grails' validation API into a Spring-free plugin. He did it mainly because he needed the behavior for an application he was working on. We're so glad he decided to open source the plugin immediately, as feedback flows in both directions without barriers (one of the major advantages of open source ).

These days the team is getting ready for two big overhauls that should result in better performance during buildtime and a faster/smarter build for the framework itself (we switched to Gradle a year ago but we haven't really tapped into it, yet). In the meantime you can enjoy interesting features like

• Building a 98% Java based Griffon application. Say what? Aha! You thought that because Griffon is based in Grails this means that applications must be written in Groovy? Well, not really. You can write any artifact in Java (you can even use Scala or Mirah if you're feeling adventurous). This is possible because every single Griffon artifact is backed by an specific type (an interface) and a default implementation. These things are weaved during compilation (weaved is a misnomer; in Groovy terms we apply AST transformations). Want to give it a try? Just type the following command.
  
  
  griffon create-app sample -fileType=java
  
  Now you have an application with the initial MVC written in Java. Look into the lifecycle directory. You'll see that the scripts have been replaced by Java classes too. Hey, even the global event handler (Events.groovy) can be written in Java, leaving only the basic configuration files in Groovy source.
• While we're on the topic of Java, have you ever wanted to apply Groovy-like AST transformations to Java code? Look no further, Project Lombok is your choice. It so happens that Griffon has a Lombok plugin that allows you to apply @Bindable to Java source code for example. Neat, huh?
• Application archetypes. This feature has the potential to change how an application is bootstrapped in the first place. You can catch a glimpse of it when using the included jumpstart archetype, like this
  
  
  griffon create-app sample -archetype=jumpstart
  
  Go ahead, give it a try. Also, why don't you append -fileType=java to it. That's right. You get a full Java application boostrapped using the jumpstart archetype.
• We may not be ready with GORM but we have persistence ready plugins like GSQL, ActiveJDBC, EBean, MyBatis, Db4o, Carbonado, Neodatis, and may other popular NoSQL alternatives

Expect a few interesting features in the path to 1.0. But, if you can't wait until then or if you have a cool feature or a useful fix then go ahead, fork us at github and send us a pull request!

Here's to the first 3 years of development of the most exciting piece of code I've been involved. Looking forward to the following years

Keep on Groovying!

The latest Griffon release (0.9.3) is ready for download!

This release comes with plenty of new features and bug fixes. The following is by no means a complete breakdown of all the things you'll find. Refer to the Release Notes to get the full list of items and issues fixed.

Let's start with the update that many were expecting to happen: the jump to Groovy 1.8. this particular version of Groovy comes packed with lots of improvements, as it can be observed in the release notes for 1.8.0 and 1.8.1. New AST transformations like @Log and @Canonical are now at your disposal; stop writing boiler-plate code when you can let the compiler do the heavy lifting

Next is the fully revamped Java support. For example, it's now possible to write a Griffon application with 98% Java code. All artifacts, lifecycle and event handlers can be written in Java source (or Scala, Mirah and/or Clojure for that matter). It's also possible to write a plugin/addon in Java as well. Even the jumpstart archetype has received a facelift. You can create a Java based application with this archetype using the following command


If you look closely at the generated files you'll discover that every single one of the source files is Java based, except of the configuration files found in griffon-app/conf (though the general events handler is Java (Events.java)).

If you're keen of using an IDE for your Groovy development activities you may be aware that both IDEA and Eclipse have a feature that enables code suggestion for dynamic code. This feature is called GDSL and DSLD respectively. Griffon includes DSL descriptors for both technologies, allowing you to invoke code completion in View scripts and AST injected methods.

In terms of packaging, the application's manifest entries are fully customizable. You can define new entries and even rewrite standard ones. Single jar packaging had a problem when duplicate file paths were encountered. Most often than not the new file would be discarded and the old one kept. Well not anymore. You can specify a merging strategy per path using regular expressions. There are plenty of options to choose from.

Looking at the runtime enhancements, there's been a lot of work to make the size of the runtime library as small as possible. Griffon 0.9.3 is approximately 25% smaller and it even includes new features! For example there's a logging appender that translates logging events into application events, useful for routing a logging statement into a status console or display an error dialog when an error is logged. Building MVC groups is the bread and butter of a medium to complex application. Some of those groups are intended to be used in a short period of time and then be discarded. While doing so it's important to remember the lifecycle of a group. That or just use the new set of withMVCGroup() methods that relieve you of the burden of keeping tabs on the group's state. Here's one example, assuming that the group display is a Dialog based groupwithMVCGroup('display') { m, v, c -> m.title = 'Information' m.message = 'Something cool is about to happen' c.show() }In case you're wondering how this code would look in JavawithMVCGroup("display", new MVCClosure<DisplayModel, DisplayView, DisplayController>(){ public void call(DisplayModel m, DisplayView v, DisplayController c) { m.setTitle("Information"); m.setMessage("Something cool is about to happen"); c.show(); } }) Byte code injection via AST transformations has become a staple of Griffon. All AST transformations have been relocated to package griffon.transform to keep them aligned with the transformations found in Groovy 1.8 (most of them living under groovy.transform). There are two transformations new to this set:

• @ThreadingAware - injects the griffon.core.ThreadingHandler interface. Pretty much makes the class aware of Griffon's threading facilities.
• @MVCAware - injects the griffon.core.MVCHandler interface. Allows the enhanced class to work with MVC groups as if it were a Griffon artifact itself.

Now, some of these enhancements and bug fixes come with a price. Griffon 0.9.3 breaks binary compatibility with previous releases as some classes were relocated, renamed or simply removed. It's worth mentioning that on the road to 1.0 all deprecated methods and classes will be removed from the codebase. It would be a good idea to review the list of breaking changes found in the release notes.

OK on to the last bits of release goodness. There are new plugins as well as updates to existing ones. Here's a quick summary:

• Actions - automatic action management, complete with i18n customizations.
• Lombok - apply AST transformations to Java code.
• Datasource - multiple datasource support.
• ActiveJdbc - lite ORM inspired in RoR's ActiveRecord.
• Ebean - another lightweight ORM solution, supports JPA.
• MyBatis - yet another lite ORM solution.
• Carbonado - what?! another ORM solution? you betcha

While the updated plugins are:

• Weld - enables addons to contribute beans to the BeanManager.
• GSQL - leverages the Datasource plugin to provide multiple datasource access.

All in all this release raises the bar once more, paving the way for the highly sought 1.0 release. Many thanks to everyone that contributed issue reports, patches, questions and feedback. We look forward to your contributions, remember you can fork us at github

Keep on Groovying!

Hace un par de semanas tuve el honor de ser invitado a participar en la serie de podcasts de JavaHispano. La entrevista corrió por parte de Jorge Rubira, a quien tuve el placer de conocer personalmente en Spring I/O Madrid 2011 (ojo chavos en México, se rumora por ahi que habrá otra edición en la Ciudad de México durante el verano).

El tema del podcast en esta ocasión fue Griffon. La secuencia de preguntas estuvo influenciada por la presentación que di en Spring I/O (la cual se encuentra disponible en SlideShare, el código de ejemplo tambieén esta disponible en Github [aqui]).

Liga a la entrevista. Todo comentario es bienvenido

Here's another quick Griffon howto. In the last two posts I showed a brand new feature found in Griffon 0.9.2, the ability to handle uncaught exceptions, and building a custom MVC group to handle error dialogs. I mentioned at the end that perhaps it would be a good idea to group several dialogs in a plugin, so that they could be reused in several applications. And that's precisely what we're going to do.

The plugin workflow is very similar to Grails

1. create a plugin project
2. configure dependencies as needed
3. add relevant source code and artifacts
4. package the plugin

However there's a small but important difference in Griffon: plugins can only affect an application during build time. That is, they can provide new dependencies, new command targets (scripts) or create artifacts. For anything else that must be executed at runtime you must create an Addon. Addons are then the runtime counterpart of plugins. An addon is nothing more than a bunch of classes and a very special class that describes the Addon's capabilities. But will see that in a moment, first we must create a plugin project.


A Griffon plugin project has pretty much the same structure as an application but you can't run it as one (another difference with Grails where you can actually perform this action). The project also includes a very special filed called the plugin descriptor, which in our case is named DialogsGriffonPlugin.groovy. This file describes what the plugin requires in order to be installed in an application (like Griffon version, dependencies, UI toolkit, OS platform) and pointers to additional documentation. Open the file in your favorite editor and make the following changes

DialogsGriffonPlugin.groov class DialogsGriffonPlugin { // the plugin version def version = "0.1" // the version or versions of Griffon the plugin is designed for def griffonVersion = '0.9.2 > *' // the other plugins this plugin depends on def dependsOn = [nuvolaicons: 0.2] // resources that are included in plugin packaging def pluginIncludes = [] // the plugin license def license = 'Apache Software License 2.0' // Toolkit compatibility. No value means compatible with all // Valid values are: swing, javafx, swt, pivot, gtk def toolkits = ['swing'] // Platform compatibility. No value means compatible with all // Valid values are: // linux, linux64, windows, windows64, macosx, macosx64, solaris def platforms = [] def author = 'Your name' def authorEmail = '' def title = 'Plugin summary/headline' def description = ''' Brief description of the plugin. ''' // URL to the plugin's documentation def documentation = 'http://griffon.codehaus.org/Dialogs+Plugin' }The dialog built in the last post requires that the NuvolaIcons plugin be installed too. We can force the installation of the plugin by setting a dependency on it. Now, every time a developer installs the dialogs plugin the nuvolaicons plugin will follow if it's not installed already.

Step #2 is creating the addon descriptor. This task can be done by invoking the following command


The convention is that the addon's name follows the plugin's but it's not enforced, you can pick any name you want. This command will perform the following tasks for you

• create the addon descriptor file named DialogsGriffonAddon.groovy
• add addon install instructions to scripts/_Install.groovy
• addd addon removal instructions to scripts/_Uninstall.groovy
• addd compile dependency on the addon's jar to scripts/_Events.groovy

Addons provide new behavior at runtime, which means the application should be aware of them in the first place. That's precisely what the install hook does. In the same vein, you must remove any hooks if the plugin is uninstalled. Now, an addon can provide many things at runtime. For example, it can add new nodes to the builder (that's precisely how the nuvolaIcon() node is added by the NuvolaIcons addon). It can also add new methods and properties, builder delegates (like those described here), application event handlers, and react to the application's life cycle. All these things are hinted in the Addon descriptor as commented out code. What you don't see however is the hint for MVC groups to be delivered by an Addon. Don't be fooled though, addons can deliver any Griffon artifact, even MVC groups, as we'll see in just a bit.

Step #3. Remember how we created the MVC group before? Right, by means of a griffon command


This time we have chosen a name with a package. The command should create the following files

• griffon-app/models/griffon/plugins/dialogs/ErrorDialogModel.groovy
• griffon-app/views/griffon/plugins/dialogs/ErrorDialogView.groovy
• griffon-app/controllers/griffon/plugins/dialogs/ErrorDialogController.groovy

If you look inside the addon descriptor class you'll find that the code has been updated too
class DialogsGriffonAddon { def mvcGroups = [ // MVC Group for "griffon.plugin.dialogs.ErrorDialog" 'ErrorDialog' : [ model : 'griffon.plugin.dialogs.ErrorDialogModel', view : 'griffon.plugin.dialogs.ErrorDialogView', controller : 'griffon.plugin.dialogs.ErrorDialogController' ] ] }There's a definition for the MVC group we just created. Awesome! Recall that addons can deliver application event handlers. Also recall from the previous post that we registered an application event handler in order to listen to uncaught exception events. What follows is that we can add the event handler to the addon, making it an integral part of it, thus the application developer no longer has to write a custom handler in griffon-app/conf/Events.groovy. WIN! The following snippet shows the final code for the addon descriptor
class DialogsGriffonAddon { def mvcGroups = [ // MVC Group for "griffon.plugin.dialogs.ErrorDialog" 'ErrorDialog' : [ model : 'griffon.plugin.dialogs.ErrorDialogModel', view : 'griffon.plugin.dialogs.ErrorDialogView', controller : 'griffon.plugin.dialogs.ErrorDialogController' ] ] def events = [ UncaughtExceptionThrown: { x -> withMvcGroup('ErrorDialog') { m, v, c -> m.title = 'Somebody setup us the bomb!' m.message = """ Oops! An unexpected error occurred and we do not know what to do with it. However instead of crashing we thought you would like to know that the problem was caused by a $x Also, look at the logging information printed in your console. For great justice! """.stripIndent(12) c.show() } } ] private withMvcGroup = { String type, Closure callback -> try { callback(*app.createMVCGroup(type)) } finally { app.destroyMVCGroup(type) } } }Pay close attention to the name of the event we choose this time: UncaughtExceptionThrown. The addon cannot know in advance the type of exception it should handle, so we declare our intention to handle any exception that might have been caught by GriffonExceptionHandler.

The next step (#4 if you're keeping count) is to fill in the details of the ErrorDialog group. You can copy the snippets from the previous post into their respective new places taking into account the changes in the package and class names.

The last step is to package the plugin and test it on an application. Packaging plugins in Griffon is done in the same way as in Grails, with one additional change: specify a -nodoc if you want a speedy build and avoid javadoc construction


The command should have created a file named griffon-dialogs-0.1.zip. You can then go an install this plugin in an application, like this


The output of the last command should result in something similar to this

Welcome to Griffon 0.9.2 - http://griffon.codehaus.org/ Licensed under Apache Standard License 2.0 Griffon home is set to: /usr/local/griffon Base Directory: /private/tmp/sample Resolving dependencies... Dependencies resolved in 569ms. Running script /usr/local/griffon/scripts/InstallPlugin.groovy Environment set to development Installing zip /private/tmp/dialogs/griffon-dialogs-0.1.zip... ... [mkdir] Created dir: /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/dialogs-0.1 [unzip] Expanding: /private/tmp/dialogs/griffon-dialogs-0.1.zip into /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/dialogs-0.1 Installed plugin dialogs-0.1 to location /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/dialogs-0.1. ... Plugin dependency [nuvolaicons] not found. Attempting to resolve... ... Resolving plugin nuvolaicons. Please wait... Installing zip /Users/aalmiray/.ivy2/cache/org.codehaus.griffon.plugins/nuvolaicons/zips/nuvolaicons-0.2-jar.zip... ... [mkdir] Created dir: /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/nuvolaicons-0.2 [unzip] Expanding: /Users/aalmiray/.ivy2/cache/org.codehaus.griffon.plugins/nuvolaicons/zips/nuvolaicons-0.2-jar.zip into /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/nuvolaicons-0.2 Installed plugin nuvolaicons-0.2 to location /Users/aalmiray/.griffon/0.9.2/projects/sample/plugins/nuvolaicons-0.2. ... Resolving plugin JAR dependencies ... Plugin license for nuvolaicons-0.2 is 'GNU LGPL 2.1' Executing nuvolaicons-0.2 plugin post-install script ... Adding NuvolaiconsGriffonAddon to Builder.groovy Plugin nuvolaicons-0.2 installed Plugin provides the following new scripts: ------------------------------------------ griffon nuvola-icon-selector Resolving plugin JAR dependencies ... Plugin license for dialogs-0.1 is 'Apache Software License 2.0' Executing dialogs-0.1 plugin post-install script ... Adding DialogsGriffonAddon to Builder.groovy Plugin dialogs-0.1 installed

Now, edit the application by adding a few conditions that will make it fail. Run the application and trigger those failing conditions. You should see the ErrorDialog appear as soon as an exception reaches GriffonExceptionHandler. That concludes today's Griffon howto.

Keep on Groovying!

In the previous post, Griffon: Dealing with uncaught exceptions, a screenshot of a dialog appeared at the end, which is reproduced here for your viewing pleasure


This dialog is intended as an error witness informing the user that something unexpected happened but that the application did not crash. Being a dialog with a single action you might wonder why spend all the effort in making an MVC group for it? There are a couple of reasons why this would be a good thing actually:

1. Both the message and title can be parameterized. Maybe bindings can be used to our advantage.
2. Showing the dialog at the correct place with the proper modal behavior requires more than just setting visible = true on a dialog.

We can leave the first task to bindings between the Model and View portions. The second task can easily be achieved by the Controller. Alright, let's begin then. Assuming you're already working with a Griffon application then the following command should be enough to create the new group


In my case this command will generate the following files

• griffon-app/models/bomb/DialogModel.groovy
• griffon-app/views/bomb/DialogView.groovy
• griffon-app/controllers/bomb/DialogController.groovy

We'll review each file in that order, starting with the Model. We said that a dialog of this kind might want to parameterize its tile and message, so let's add two properties to the model
package bomb class DialogModel { @Bindable String title = 'Error' @Bindable String message = '' }Do you notice something missing in the code? Where's the import statement for groovy.beans.Bindable? Just like Groovy will automatically import some packages like java.io and java.util Griffon does something similar, through additional default imports, which are of course configurable, even per artifact type. Good, let's turn our gaze to the View now
package bomb optionPane( id: 'pane', messageType: JOptionPane.INFORMATION_MESSAGE, optionType: JOptionPane.DEFAULT_OPTION, icon: nuvolaIcon('core', category: 'apps', size: 64), message: bind {model.message})The View is actually a JOptionPane so it is not a dialog per se (yet). Notice again the usage of default imports in action (we needn't import javax.swing.JOptionPane). The View does have a binding to one of the Model's properties (the message property), it's very likely that we'll see the other property at play with the Controller. Oh, in case you wonder what does that nuvolaIcon node do it basically renders an specific Icon from the NuvolaIcons plugin. Time to look at the final piece of the MVC group, the Controller
package bomb import java.awt.Window class DialogController { def model def view @Threading(Threading.Policy.INSIDE_UITHREAD_SYNC) def show = { Window window = null -> view.pane.createDialog( window ?: Window.windows.find{it.focused}, model.title).show() } }This controller makes sure that the show action is executed synchronously inside the UI thread using an annotation that generates specific byte code through the usage of Groovy's AST transformation framework (have a look at section 9.3 of the Griffon Guide to learn more about the different options). The action makes sure to locate a suitable parent Window for the dialog it will create, that is, if the passed in window turns out to be invalid.

Perfect, now we can wire this dialog with the uncaught exception handler shown in the previous post. Locate griffon-app/conf/Events.groovy and edit it, make sure it looks like the following snippet
import griffon.util.ApplicationHolder import griffon.core.GriffonApplication onUncaughtBombException = { x -> withMvcGroup('dialog') { m, v, c -> m.title = 'Somebody setup us the bomb!' m.message = """ Oops! An unexpected error occurred and we do not know what to do with it. However instead of crashing we thought you would like to know that the problem was caused by a $x Also, look at the logging information printed in your console. For great justice! """.stripIndent(12) c.show() } } withMvcGroup = { String type, Closure callback -> GriffonApplication app = ApplicationHolder.application try { callback(*app.createMVCGroup(type)) } finally { app.destroyMVCGroup(type) } }The handler makes use of a helper method that instantiates the group and cleans up after it has been discarded. This method has been suggested a few times in the past and will be featured in a future Griffon release (see GRIFFON-345), but for now we have to write our own.

A group such as this one can come in handy for more than just one application. It probably is a good idea to package it in a plugin, perhaps one that supplies different types of dialogs, for example: AboutDialog, ErrorDialog (like this one), etc. I'll cover how such a plugin can be created in a future post. Full code for the application shown here can be browsed/forked/downloaded from here.

Keep on Groovying!