Griffon: new release means new plugins too
During the past weeks there was a series of sneak peeks on features available in the soon-to-be-released Griffon 0.9, as a summary:The good news is that the latest release has arrived! You'll find the full list of changes here. It is a well known fact that with every Griffon release a set of new plugins become available. However in this case the set's size is bigger than usual; here's a quick rundown on what you can expect.
Layouts As Geertjan prophesied in MigLayout: Inevitable Choice for Griffon Users?, MigLayout is now available as a plugin. But it's not alone, there are other layout alternatives in the form of DesignGridLayout, RiverLayout and ZoneLayout.
Look & Feel Java Swing applications have always been attacked as not looking native enough (or even good enough). No problem, just install the LookAndFeel plugin and you get a configurable way to change the Look & Feel, even after the UI has been displayed. Many Swing developers will agree that the most versatile and elegant L&F theme collection is found in the Substance project, you'll be happy to know that Substance is available as a pluggable L&F provider, along with A03, EaSynth, JGoodies Looks, JTattoo, Kunststoff, Liquid, Metouia, Napkin, NimROD, OfficeLnfs, Pagosoft, Skin, Squareness, Tinylaf and Tonic.
Effects and Glitz Closely related to the L&F topic are effects and additional glitz; basically stuff that makes your apps look better while improving the user experience. There's a new group of plugins that provide well know icon sets, like Everaldo's Crystal, Tango! and Mark James' Silk collection. They are joined by Nuvola, Feeds and Countries (also from Mark James' famfamfam flag icons).
The Effects plugin brings you script.aculo.us inspired effects, and while the current number of effects is less than the original you can expect more to be added at a later stage. Charting is now easier thanks to the Charts plugin, which bundles Groovychart, a Groovy builder for JFreeChart. Making graph visualizations is also simple with the JGraph plugin. Lastly, the JXLayer plugin paves the way for compatibility with the upcoming JLayer from JDK7.
Testing You'll find a totally revamped testing infrastructure as one of the biggest changes in Griffon 0.9's buildtime package. This change allows for a new kind of plugins to be built, perhaps the most awaited one is the Spock plugin as it opens the door for a wide range of options. This plugin is a direct port of it's Grails counterpart. Clover is another port from Grails, also marking the first release of a Griffon plugin from a commercial offering.
Persistence On the persistence front we find two new plugins focused on NoSQL: Riak and Memcached. The latter comes with the 3 most popular java clients for connecting to memcached/membase servers, giving you the option to pick and choose the one you like best.
General Finally we also get the Maven Publisher plugin (another port from Grails). This plugin helps in publishing/deploying plugins and applications to Maven repositories, a perfect companion to Griffon's new Dependency DSL mechanism (also borrowed from Grails).
All in all 36 new releases, not bad
Most of the already existing plugins have had releases too, upgrading themselves to Griffon 0.9 and adding a few features. And there are more new plugins coming in the future: 3D support, NoSQL, domain classes, scaffolding, etc.
Keep on Groovying!
Layouts As Geertjan prophesied in MigLayout: Inevitable Choice for Griffon Users?, MigLayout is now available as a plugin. But it's not alone, there are other layout alternatives in the form of DesignGridLayout, RiverLayout and ZoneLayout.
Look & Feel Java Swing applications have always been attacked as not looking native enough (or even good enough). No problem, just install the LookAndFeel plugin and you get a configurable way to change the Look & Feel, even after the UI has been displayed. Many Swing developers will agree that the most versatile and elegant L&F theme collection is found in the Substance project, you'll be happy to know that Substance is available as a pluggable L&F provider, along with A03, EaSynth, JGoodies Looks, JTattoo, Kunststoff, Liquid, Metouia, Napkin, NimROD, OfficeLnfs, Pagosoft, Skin, Squareness, Tinylaf and Tonic.
Effects and Glitz Closely related to the L&F topic are effects and additional glitz; basically stuff that makes your apps look better while improving the user experience. There's a new group of plugins that provide well know icon sets, like Everaldo's Crystal, Tango! and Mark James' Silk collection. They are joined by Nuvola, Feeds and Countries (also from Mark James' famfamfam flag icons).
The Effects plugin brings you script.aculo.us inspired effects, and while the current number of effects is less than the original you can expect more to be added at a later stage. Charting is now easier thanks to the Charts plugin, which bundles Groovychart, a Groovy builder for JFreeChart. Making graph visualizations is also simple with the JGraph plugin. Lastly, the JXLayer plugin paves the way for compatibility with the upcoming JLayer from JDK7.
Testing You'll find a totally revamped testing infrastructure as one of the biggest changes in Griffon 0.9's buildtime package. This change allows for a new kind of plugins to be built, perhaps the most awaited one is the Spock plugin as it opens the door for a wide range of options. This plugin is a direct port of it's Grails counterpart. Clover is another port from Grails, also marking the first release of a Griffon plugin from a commercial offering.
Persistence On the persistence front we find two new plugins focused on NoSQL: Riak and Memcached. The latter comes with the 3 most popular java clients for connecting to memcached/membase servers, giving you the option to pick and choose the one you like best.
General Finally we also get the Maven Publisher plugin (another port from Grails). This plugin helps in publishing/deploying plugins and applications to Maven repositories, a perfect companion to Griffon's new Dependency DSL mechanism (also borrowed from Grails).
All in all 36 new releases, not bad
Most of the already existing plugins have had releases too, upgrading themselves to Griffon 0.9 and adding a few features. And there are more new plugins coming in the future: 3D support, NoSQL, domain classes, scaffolding, etc.Keep on Groovying!
Categories: Blogs
Griffon 0.9 sneak peek: runtime enhancements
Today's post on Griffon 0.9 updates is related to runtime enhancements, previous posts were all about build time. Be warned that there are some breaking changes here too, all for the best of course.
1. Addon enhancements The first update has to do with Addons. Contributing new nodes, methods and properties to builders is fairly simple, the following line is added to the plugin's install script by the create-addon command:
Given that addons are a natural extension to builders, and that builders can contribute methods and properties to other MVC members (like controllers for example), it follows that addons should do the same, but the syntax was not that pretty. Assuming MyGriffonAddon contributes 2 factories (foo and bar) plus an additional method (hello), this is how you would added them to a controller:
In other words, you have to enumerate all entries that should be contributed
This is the problem addressed by this enhancement. Now you only need to write '*' to mixin all addon contributions to a particular MVC member. The previous code can be rewritten as:
You might be thinking, what if all methods should be contributed only? This does the trick
The whole list of these new contribution qualifiers follows:
Griffon 0.3.1 added shortcut versions (execSync, execAsync, execOutside, execFuture) to all MVC members and the application instance, thus allowing the following snippets to work
// in a controller class MyController { def myService def model def action = { execOutside { myService.work(model) } } } // in a service class MyService { def app def work(model) { // compute long calculation result = ... app.execSync { model.result = result } } }
This update allows the shortcut methods to be used inside life cycle scripts, thus pushing down the need to call UIThreadHelper.instance directly.
3. Application phase There's a new enum (griffon.core.ApplicationPhase) that can be used to know in which phase the application is currently is. Its values are INITIALIZE, STARTUP, READY, MAIN and SHUTDOWN; you can query it by calling getPahse() on the application instance.
4. Application locale All applications now have a bound java.util.Locale property. This means you can register PropertyChangeListeners on an application and be notified whenever their locale changes value.
5. Swing enhancements While all previous updates are applied to all applications, the following one is Swing specific (remember that Griffon can support more toolkits other than Swing via plugins).
5.1 Shortcut for registering PropertyChangeListeners Registering PropertyChangeListeners just got a bit easier, thanks to the new @Listener AST transformation. Before this enhancement you had to write the following code
import groovy.beans.Bindable import java.beans.PropertyChangeListener class MyModel { @Bindable String name @Bindable String lastname @Bindable boolean enabled = false @Bindable String group MyModel() { addPropertyChangeListener({ if(evt.propertyName == 'enabled') return enabled = name && lastname } as PropertyChangeListener) addPropertyChangeListener('name', updateGroup as PropertyChangeListener) } private updateGroup = { group = (it.newValue ?: ' ')[0].toUpperCase() } }
Basically you were forced to register the listeners inside a constructor, you also had to cast any closures to an appropriate value. Well, not anymore. Here's the same behavior using @Listener instead
import groovy.beans.Bindable import griffon.beans.Listener @Listener(enabler) class MyModel { @Listener({ group = (it.newValue ?: ' ')[0].toUpperCase() }) @Bindable String name @Bindable String lastname @Bindable boolean enabled = false @Bindable String group private enabler = { if(evt.propertyName == 'enabled') return enabled = name && lastname } }
A List of property closures or inline closures is also supported as value for the @Listener annotation.
5.2 Window management There's a new set of helper classes, WindowManager and WindowDisplayHandler that let you change the default behavior for showing and hiding windows. This new feature receives a boost from the upcoming Effects plugin. For example this is all that you have to do for enabling a dropIn/dropOut effect when showing/hiding windows
1. install the Effects plugin
2. Create a class that implements WindowDisplayHandler with the following contents
import java.awt.Window import griffon.swing.SwingUtils import griffon.swing.WindowDisplayHandler import griffon.core.GriffonApplication import griffon.effects.Effects class Dropper implements WindowDisplayHandler { void show(Window window, GriffonApplication app) { SwingUtils.centerOnScreen(window) app.execOutside { Effects.dropIn(window, wait: true) } } void hide(Window window, GriffonApplication app) { app.execOutside { Effects.dropOut(window, wait: true) } } }
3. Register an instance of this handler with the application. It can be done on a life cycle script (like Initialize or Startup) or by using an application event handler (griffon-app/conf/Events.groovy)
onBootstrapEnd = { app -> app.windowDisplayHandler = new Dropper() }
WindowManager is now responsible for holding a reference to all application windows that are created using the application node. This used to be the job of app.appFrames which is no longer available, developers should rely on app.windowManager.windows from now one. Windoes that were not created using the application node can still be handled by WindowManager, just call its attach() method with the window instance that should be handled.
Keep on Groovying!
1. Addon enhancements The first update has to do with Addons. Contributing new nodes, methods and properties to builders is fairly simple, the following line is added to the plugin's install script by the create-addon command:
root.'MyGriffonAddon'.addon = true
Given that addons are a natural extension to builders, and that builders can contribute methods and properties to other MVC members (like controllers for example), it follows that addons should do the same, but the syntax was not that pretty. Assuming MyGriffonAddon contributes 2 factories (foo and bar) plus an additional method (hello), this is how you would added them to a controller:
root.'MyGriffonAddon'.controller = ['foo', 'bar', 'hello']
In other words, you have to enumerate all entries that should be contributed
This is the problem addressed by this enhancement. Now you only need to write '*' to mixin all addon contributions to a particular MVC member. The previous code can be rewritten as:
root.'MyGriffonAddon'.controller = '*'
You might be thinking, what if all methods should be contributed only? This does the trick
root.'MyGriffonAddon'.controller = '*:methods'
The whole list of these new contribution qualifiers follows:
- * - all nodes, methods and properties
- *:factories - nodes only
- *:methods - methods only
- *:props - properties only
- isUIThread() - true if the current thread is identified as the UI thread for the current toolkit. Equivalent to SwingUtilities.isEventDispatchThread() when running Swing
- executeSync() - execute code synchronously inside the UI thread. Equivalent to SwingBuilder.edt() when running Swing
- executeAsync() - execute code asynchronously inside the UI thread. Equivalent to SwingBuilder.doLater() when running Swing
- executeOutside() - execute code outside of the UI thread. Equivalent to SwingBuilder.doOutside() when running Swing
UIThreadHelper.instance.executeSync { model.enabled = true }Griffon 0.3.1 added shortcut versions (execSync, execAsync, execOutside, execFuture) to all MVC members and the application instance, thus allowing the following snippets to work
// in a controller class MyController { def myService def model def action = { execOutside { myService.work(model) } } } // in a service class MyService { def app def work(model) { // compute long calculation result = ... app.execSync { model.result = result } } }
This update allows the shortcut methods to be used inside life cycle scripts, thus pushing down the need to call UIThreadHelper.instance directly.
3. Application phase There's a new enum (griffon.core.ApplicationPhase) that can be used to know in which phase the application is currently is. Its values are INITIALIZE, STARTUP, READY, MAIN and SHUTDOWN; you can query it by calling getPahse() on the application instance.
4. Application locale All applications now have a bound java.util.Locale property. This means you can register PropertyChangeListeners on an application and be notified whenever their locale changes value.
5. Swing enhancements While all previous updates are applied to all applications, the following one is Swing specific (remember that Griffon can support more toolkits other than Swing via plugins).
5.1 Shortcut for registering PropertyChangeListeners Registering PropertyChangeListeners just got a bit easier, thanks to the new @Listener AST transformation. Before this enhancement you had to write the following code
import groovy.beans.Bindable import java.beans.PropertyChangeListener class MyModel { @Bindable String name @Bindable String lastname @Bindable boolean enabled = false @Bindable String group MyModel() { addPropertyChangeListener({ if(evt.propertyName == 'enabled') return enabled = name && lastname } as PropertyChangeListener) addPropertyChangeListener('name', updateGroup as PropertyChangeListener) } private updateGroup = { group = (it.newValue ?: ' ')[0].toUpperCase() } }
Basically you were forced to register the listeners inside a constructor, you also had to cast any closures to an appropriate value. Well, not anymore. Here's the same behavior using @Listener instead
import groovy.beans.Bindable import griffon.beans.Listener @Listener(enabler) class MyModel { @Listener({ group = (it.newValue ?: ' ')[0].toUpperCase() }) @Bindable String name @Bindable String lastname @Bindable boolean enabled = false @Bindable String group private enabler = { if(evt.propertyName == 'enabled') return enabled = name && lastname } }
A List of property closures or inline closures is also supported as value for the @Listener annotation.
5.2 Window management There's a new set of helper classes, WindowManager and WindowDisplayHandler that let you change the default behavior for showing and hiding windows. This new feature receives a boost from the upcoming Effects plugin. For example this is all that you have to do for enabling a dropIn/dropOut effect when showing/hiding windows
1. install the Effects plugin
2. Create a class that implements WindowDisplayHandler with the following contents
import java.awt.Window import griffon.swing.SwingUtils import griffon.swing.WindowDisplayHandler import griffon.core.GriffonApplication import griffon.effects.Effects class Dropper implements WindowDisplayHandler { void show(Window window, GriffonApplication app) { SwingUtils.centerOnScreen(window) app.execOutside { Effects.dropIn(window, wait: true) } } void hide(Window window, GriffonApplication app) { app.execOutside { Effects.dropOut(window, wait: true) } } }
3. Register an instance of this handler with the application. It can be done on a life cycle script (like Initialize or Startup) or by using an application event handler (griffon-app/conf/Events.groovy)
onBootstrapEnd = { app -> app.windowDisplayHandler = new Dropper() }
WindowManager is now responsible for holding a reference to all application windows that are created using the application node. This used to be the job of app.appFrames which is no longer available, developers should rely on app.windowManager.windows from now one. Windoes that were not created using the application node can still be handled by WindowManager, just call its attach() method with the window instance that should be handled.
Keep on Groovying!
Categories: Blogs
Griffon 0.9-SNAPSHOT available
I'm very happy to announce that Griffon 0.9-SNAPSHOT is available for download. The release notes cover what's new and what's been changed in this release. Some of these features have been discussed in this blog on previous posts:
The Griffon team welcomes all feedback. For example there's one bug in this release that has already been fixed (GRIFFON-251).
Keep on Groovying!
Keep on Groovying!
Categories: Blogs
Griffon 0.9 sneak peek: infrastructure updates
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:
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!
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.
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!
Categories: Blogs
Griffon 0.9 sneak peek: packaging
The next set of new features to be found in the upcoming Griffon 0.9 release are related to packaging.
1. META-INF resources Dealing with META-INF resources in a cross platform independent way is not as easy as it sounds given that some versions of Windows simply disregard directory names with all caps and treat them as all lower caps. But Ant knows how to deal with this problem, and given that Gant is built on top of Ant so does Griffon. Placing a file under griffon-app/conf/metainf means it will be packaged inside the jar's META-INF directory. It even works for any directories you place there. As an added benefit of this new resource location is that all resources that are placed there will also be transparently available during testing, your code won't know the difference.
2. Plugin packaging Plugins have received a huge face lift in this release, one of the main areas is packaging. During plugin/addon packaging the following jars may be generated
Keep on Groovying!
1. META-INF resources Dealing with META-INF resources in a cross platform independent way is not as easy as it sounds given that some versions of Windows simply disregard directory names with all caps and treat them as all lower caps. But Ant knows how to deal with this problem, and given that Gant is built on top of Ant so does Griffon. Placing a file under griffon-app/conf/metainf means it will be packaged inside the jar's META-INF directory. It even works for any directories you place there. As an added benefit of this new resource location is that all resources that are placed there will also be transparently available during testing, your code won't know the difference.
2. Plugin packaging Plugins have received a huge face lift in this release, one of the main areas is packaging. During plugin/addon packaging the following jars may be generated
- griffon-<name>-<version>-sources.jar - contains all source files from griffon-app/*, src/main, src/test and additional source directories configured in Buildconfig.groovy
- griffon-<name>-<version>-javadoc.jar - contains groovydocs generated for all sources.
- griffon-<name>-<version>-test.jar - contains all compiled tests sources form src/test and all test resources from test/resources
griffon prepare-izpack griffon create-izpackStarting in Griffon 0.9 and with the next release of the Installer plugin (0.5) you will be able to call those additional packaging targets as if they were there by default, for example
griffon package izpackThis integration is done via build events so you can hook up other install targets in the same way.
Keep on Groovying!
Categories: Blogs
Griffon 0.9 sneak peek: testing upgrades
Continuing the peek parade (previous entries on command line features and application archetypes) we'll look at what's new regarding testing in Griffon.
The first thing you'll notice is that executing tests is done in the same way as in Grails. This is because Griffon's build system has been refreshed with the latest Grails 1.3.2 codebase. Now you can run all tests using the same phase:type mechanism that Grails has. Griffon has 3 phases (unit, integration and other) and two default types (unit and integration). Those two types are actually JUnit based tests cases, it has been pointed out that perhaps those types should be coalesced into a single one: junit.
Say you'd like to run all JUnit tests in the unit phase, this is what you must type
Back to test-app. this command is very flexible with its options. Do you need to run all tests that affect all services?
Following into testing related plugins, there are 4 other direct ports of Grails plugins into Griffon
All in all, Griffon will help you to keep the bar green and bugs in check.
Keep on Groovying!
The first thing you'll notice is that executing tests is done in the same way as in Grails. This is because Griffon's build system has been refreshed with the latest Grails 1.3.2 codebase. Now you can run all tests using the same phase:type mechanism that Grails has. Griffon has 3 phases (unit, integration and other) and two default types (unit and integration). Those two types are actually JUnit based tests cases, it has been pointed out that perhaps those types should be coalesced into a single one: junit.
Say you'd like to run all JUnit tests in the unit phase, this is what you must type
griffon test-app :unitOn the other hand, if what you want is to exercise all unit tests regardless of their type, then invoke the following command
griffon test-app unit:Speaking of types, there are two additional types provided by plugins. The first type is easyb and the second is spock. Both plugins are direct port of their corresponding Grails counterparts (which speaks volumes in terms of compatibility between Grails and Griffon, doesn't it?). New versions of these plugins will be ready once Griffon 0.9 ships.
Back to test-app. this command is very flexible with its options. Do you need to run all tests that affect all services?
griffon test-app *ServiceWhat if what you want is to run all tests that are related to the same artifact?
griffon test-app FooControllerYou can also specify package names and even run a single test method, like this
griffon test-app com.acme.Factory.testMakeAnvilAll this is possible to the great efforts made by Luke Daley in the Grails codebase (with a big help from the rest of the Grails team too: Graeme, Peter, Jeff and Burt).
Following into testing related plugins, there are 4 other direct ports of Grails plugins into Griffon
- Code-Coverage - this one existed since the early days, however it has been synchronized to the latest codebase from its Grails counterpart
- Clover - s/grails/griffon/ did the trick for this one, just like that.
- CodeNarc - static code analysis for Groovy source? you bet!
- GMetrics - measures the size and complexity of your codebase
All in all, Griffon will help you to keep the bar green and bugs in check.
Keep on Groovying!
Categories: Blogs
Griffon 0.9 sneak peek: application archetypes
Yesterday saw the first post regarding the new features that can be found in the upcoming Griffon 0.9 release. Those features were inspired by Grails and Gradle. Today I'd like to talk about another neat feature, this time inspired by Maven. Hold on! don't go away just yet! I promise it's a good one, honest.
Since the beginning a developer was able to create new artifacts using a predefined template, usually located somewhere in the Griffon distribution install directory. Developers also had the choice to provide their own templates local to an application, or even bundle them in plugins. While all this works fine and dandy the missing piece was being able to tweak the initial MVC group that is generated when an application is created, simply because no local templates are available as the application has not been created yet; same thing with plugins.
Application archetypes fill that void.
Application archetypes are simple zip files with an application descriptor and templates. Despite this, Griffon provides a few scripts that let you manage archetypes: create-archetype, package-archetype, install-archetype, uninstall-archetype. Here's how the default archetype descriptor (application.groovy) looks
Templates are stored relative to the archetype descriptor under templates/artifacts. You're free to modify and add as many templates as needed. You can also add other files that can be copied to the application, like a LICENSE.TXT or README for example, just remember you must write the copying code yourself in the archetype descriptor.
Archetypes are registered with the application metadata so that when a new artifact is created the appropriate template is used. However if you wish to override this setting while creating an artifact then specify an -archetype=<name> argument to the create-* script. The following is the template search order
The archetype install options are very similar to plugins, you can install them from a zip file location or from an URL. There is no central management for archetypes at the moment as there is for plugins.
That's all for now. Keep on Groovying!
Since the beginning a developer was able to create new artifacts using a predefined template, usually located somewhere in the Griffon distribution install directory. Developers also had the choice to provide their own templates local to an application, or even bundle them in plugins. While all this works fine and dandy the missing piece was being able to tweak the initial MVC group that is generated when an application is created, simply because no local templates are available as the application has not been created yet; same thing with plugins.
Application archetypes fill that void.
Application archetypes are simple zip files with an application descriptor and templates. Despite this, Griffon provides a few scripts that let you manage archetypes: create-archetype, package-archetype, install-archetype, uninstall-archetype. Here's how the default archetype descriptor (application.groovy) looks
import griffon.util.Metadata
includeTargets << griffonScript("_GriffonPlugins")
includeTargets << griffonScript("_GriffonInit")
includeTargets << griffonScript("CreateMvc" )
target(createApplicationProject: 'Creates a new application project') {
createProjectWithDefaults()
createMVC()
// to install plugins do the following
// Metadata md = Metadata.getInstance("${basedir}/application.properties")
// installPluginExternal md, pluginName, pluginVersion
//
// pluginVersion is optional
}
setDefaultTarget(createApplicationProject)Let's deconstruct it piece by piece. An archetype descriptor awfully resembles your typical Griffon gant script. As a matter of fact it is your typical Griffon gant script with a predefined default target name. The name should not be changed as it is there by convention. This target creates a project using the default settings then creates the first MVC group. Notice the commented out code, it tells you that you can also install plugins during the application creation phase, ain't that great?Templates are stored relative to the archetype descriptor under templates/artifacts. You're free to modify and add as many templates as needed. You can also add other files that can be copied to the application, like a LICENSE.TXT or README for example, just remember you must write the copying code yourself in the archetype descriptor.
Archetypes are registered with the application metadata so that when a new artifact is created the appropriate template is used. However if you wish to override this setting while creating an artifact then specify an -archetype=<name> argument to the create-* script. The following is the template search order
- local to the application -> $basedir/src/templates/artifacts
- provided by a plugin -> $pluginHome/*/src/templates/artifacts
- local archetype -> ~/.griffon/<version>/archetypes/<name>/templates/artifacts
- global archetype -> $griffonHome/archetypes/<name>/templates/artifacts
The archetype install options are very similar to plugins, you can install them from a zip file location or from an URL. There is no central management for archetypes at the moment as there is for plugins.
That's all for now. Keep on Groovying!
Categories: Blogs
Griffon 0.9 sneak peek: command line updates
It's been a month a half since the last Griffon release, we're getting ready for another one, but this time it's going to be a big one. There are many updates, fixes and changes in the upcoming 0.9 release so I'll make my best to post a daily update to let you know what's coming up.
The first updates I'd like to talk about are the command line additions. There are two new features inspired by Gradle:
1. Command expansion The gradle command has this neat trick of allowing a command target to be expanded if you write it in shorthand notation using camel case. For example gradle pP expands to gradle packageProject (if such target exists anyway). This certainly saves you some keystrokes. The griffon command now has the same command expansion ability. I'm glad to say that this feature was contributed by the Hackergarten group while having an "on tour" meeting at Jazoon 2010.
Remember to write just about enough characters to let the target recognizing algorithm to resolve the name unambiguously, otherwise you'll be given a choice with the matching options, as shown next when invoking griffon rA
It's worth mentioning that if you write out the full name of a target then it will work as before, even if there is multiple potential matches. This means that typing griffon run-app will invoke the RunApp script and will not give you a choice between RunApp and RunApplet.
2. Command suggestion There might have been times when one of your fingers decided to strike the wrong key and you ended up with a typo. It is somewhat expensive to invoke the griffon command with the wrong target, as you pay the price for JVM startup and end up with an error message. Well not anymore! Straight from the recent Grails 1.3.2 release comes another command matching algorithm proposed by Seth Schroeder (Groovy cosine similarity in Grails). The algorithm kicks in if a command target is not recognized, even if the previous command expansion feature did not resolve to a known script. Here's some sample output
You might have noticed the App script as option #2. It is an alias for RunApp, so that you can type griffon a and run the application; otherwise you'll be given a list of choices as the previous griffon rA example demonstrated.
3. Command wrapper Here comes another feature inspired by Gradle. Projects built with Gradle have the option to embed a command wrapper called gradlew. This command wrapper takes care of downloading a suitable gradle distribution and execute it. This means that the project is self contained in terms of its build, so that you can freely redistribute it in source form to anyone; they will be able to build your project without needing Gradle pre-installed on their system, as long as they rely on the wrapper to call the build targets.
Well, Griffon 0.9 comes with a command wrapper too, aptly named griffonw. The wrapper and its required files will be added to every application and/or plugin created with this release and onwards. Given that the wrapper downloads, installs and runs a fully working Griffon distribution means that you can apply both features #1 and #2 with it as well.
4. Interactive mode This is not really a new feature but a reminder that you can run the griffon command in interactive form, which means you pay the cost for JVM startup once. This mode can be invoked by typing griffon interactive. Here's the output of a sample session invoking the following commands: compile, cl (shorthand for clean), and applet
That's all for today and the command line. Stay tuned for more Griffon 0.9 goodies!
Keep on Groovying!
The first updates I'd like to talk about are the command line additions. There are two new features inspired by Gradle:
1. Command expansion The gradle command has this neat trick of allowing a command target to be expanded if you write it in shorthand notation using camel case. For example gradle pP expands to gradle packageProject (if such target exists anyway). This certainly saves you some keystrokes. The griffon command now has the same command expansion ability. I'm glad to say that this feature was contributed by the Hackergarten group while having an "on tour" meeting at Jazoon 2010.
Remember to write just about enough characters to let the target recognizing algorithm to resolve the name unambiguously, otherwise you'll be given a choice with the matching options, as shown next when invoking griffon rA
$ griffon rA Welcome to Griffon 0.9 - http://griffon.codehaus.org/ Licensed under Apache Standard License 2.0 Griffon home is set to: /usr/local/griffon Base Directory: /private/tmp/bar Resolving dependencies... Dependencies resolved in 656ms. Multiple options please select: [1] /usr/local/griffon/scripts/RunApp.groovy [2] /usr/local/griffon/scripts/RunApplet.groovy Enter # [1,2]
It's worth mentioning that if you write out the full name of a target then it will work as before, even if there is multiple potential matches. This means that typing griffon run-app will invoke the RunApp script and will not give you a choice between RunApp and RunApplet.
2. Command suggestion There might have been times when one of your fingers decided to strike the wrong key and you ended up with a typo. It is somewhat expensive to invoke the griffon command with the wrong target, as you pay the price for JVM startup and end up with an error message. Well not anymore! Straight from the recent Grails 1.3.2 release comes another command matching algorithm proposed by Seth Schroeder (Groovy cosine similarity in Grails). The algorithm kicks in if a command target is not recognized, even if the previous command expansion feature did not resolve to a known script. Here's some sample output
$ griffon applet Welcome to Griffon 0.9 - http://griffon.codehaus.org/ Licensed under Apache Standard License 2.0 Griffon home is set to: /usr/local/griffon Base Directory: /private/tmp/bar Resolving dependencies... Dependencies resolved in 435ms. Running pre-compiled script Script 'Applet' not found, did you mean: 1) RunApplet 2) App 3) RunApp 4) TestApp 5) CreateApp_ Please make a selection or enter Q to quit:
You might have noticed the App script as option #2. It is an alias for RunApp, so that you can type griffon a and run the application; otherwise you'll be given a list of choices as the previous griffon rA example demonstrated.
3. Command wrapper Here comes another feature inspired by Gradle. Projects built with Gradle have the option to embed a command wrapper called gradlew. This command wrapper takes care of downloading a suitable gradle distribution and execute it. This means that the project is self contained in terms of its build, so that you can freely redistribute it in source form to anyone; they will be able to build your project without needing Gradle pre-installed on their system, as long as they rely on the wrapper to call the build targets.
Well, Griffon 0.9 comes with a command wrapper too, aptly named griffonw. The wrapper and its required files will be added to every application and/or plugin created with this release and onwards. Given that the wrapper downloads, installs and runs a fully working Griffon distribution means that you can apply both features #1 and #2 with it as well.
4. Interactive mode This is not really a new feature but a reminder that you can run the griffon command in interactive form, which means you pay the cost for JVM startup once. This mode can be invoked by typing griffon interactive. Here's the output of a sample session invoking the following commands: compile, cl (shorthand for clean), and applet
$ griffon interactive
Welcome to Griffon 0.9 - http://griffon.codehaus.org/
Licensed under Apache Standard License 2.0
Griffon home is set to: /usr/local/griffon
Base Directory: /private/tmp/bar
--------------------------------------------------------
Interactive mode ready. Enter a Griffon command or type "exit" to quit interactive mode (hit ENTER to run the last command):
compile
Resolving dependencies...
Dependencies resolved in 400ms.
Running script /usr/local/griffon/scripts/Compile.groovy
Environment set to development
[mkdir] Created dir: /Users/aalmiray/.griffon/0.9/projects/bar/classes
[mkdir] Created dir: /Users/aalmiray/.griffon/0.9/projects/bar/plugin-classes
[mkdir] Created dir: /Users/aalmiray/.griffon/0.9/projects/bar/test-classes/shared
[mkdir] Created dir: /Users/aalmiray/.griffon/0.9/projects/bar/test-resources
[groovyc] Compiling 12 source files to /Users/aalmiray/.griffon/0.9/projects/bar/classes
[groovyc] Compiling 5 source files to /Users/aalmiray/.griffon/0.9/projects/bar/classes
--------------------------------------------------------
Command Compile completed in 2896ms
--------------------------------------------------------
Interactive mode ready. Enter a Griffon command or type "exit" to quit interactive mode (hit ENTER to run the last command):
cl
Resolving dependencies...
Dependencies resolved in 2ms.
Running script /usr/local/griffon/scripts/Clean.groovy
Environment set to development
[delete] Deleting directory /Users/aalmiray/.griffon/0.9/projects/bar/classes
[delete] Deleting directory /Users/aalmiray/.griffon/0.9/projects/bar/plugin-classes
[delete] Deleting directory /Users/aalmiray/.griffon/0.9/projects/bar/test-classes
[delete] Deleting directory /Users/aalmiray/.griffon/0.9/projects/bar/test-resources
--------------------------------------------------------
Command Cl completed in 1018ms
--------------------------------------------------------
Interactive mode ready. Enter a Griffon command or type "exit" to quit interactive mode (hit ENTER to run the last command):
applet
Resolving dependencies...
Dependencies resolved in 1ms.
Running pre-compiled script
Script 'Applet' not found, did you mean:
1) RunApplet
2) App
3) RunApp
4) TestApp
5) CreateApp_
Please make a selection or enter Q to quit:
That's all for today and the command line. Stay tuned for more Griffon 0.9 goodies!
Keep on Groovying!
Categories: Blogs
Time marches on relentlessly
This blog is now 4 years old. The following 12 entries are the most viewed during that period. It is interesting to see that while most of the post written have to do with Griffon or Groovy there are also high ranking views related to JavaFX and Scala.
- 11/Jan/10 Groovy & Scala: a tale of two JVM languages
This is a reprint of an article published in GroovyMag. It shows how both languages can cooperate with each other. - 26/Nov/09 Building Rich Swing Applications with Groovy - Part I
Another GroovyMag. article reprint. This is the first of a series of articles about Groovy's SwingBuilder and eventually, Griffon - 26/Dec/09 Griffon: Beyond Swing
First hint about the multi-toolkit capabilities of Griffon 0.3 - 06/Sep/09 Groovy vs Scala...
Qualified by many as a 'bait link', this post announces the publication of the Groovy/Scala article published in GroovyMag (the same one sitting at #1). Still, looks like many expected a mud bath between Groovy and Scala *le sigh*. - 10/Jun/09 Another look at FxBuilder + Griffon
Fueled by the last JavaOne, got into JavaFX once more and updated FxBuilder. - 01/May/08 Json-lib & Hibernate: tips and hints
A popular entry from 2 years back! Having trouble serializing hibernated POJOs to JSON? Have a look at some of this tips then. - 07/Dec/09 Building Rich Swing Applications with Groovy - Part IV
Final part of the series. this article introduces Griffon by means of a simple example that goes beyond the DemoConsole. - 30/Nov/09 Building Rich Swing Applications with Groovy - Part II
Detailed explanation of the builder life cycle and a few of SwingBuilder's sibling builders. - 03/Dec/09 Building Rich Swing Applications with Groovy - Part III
Binding options in SwingBuilder are discussed. - 04/Dec/08 Some JavaFx/Java/Groovy examples
First foray into JavaFX/Groovy right after Sun announced the availability of JavaFx 1.0 (the very same day!) - 09/Jun/09 Griffon + GSQL mini howto
A post inspired by Geertjan's Griffon experiments with wizards and databases. This howto is the beginning of what later became the first official plugin/addon added to Griffon. - 16/Nov/09 Griffon: visualizing an object graph
What do you get when you mix JUNG, ObjectGraphBuilder and Griffon? A graph visualizer app with little to none effort, honest!
- 10/Jun/09 Styling a Griffon application
This post introduces CSSBuilder, a builder capable of applying CSS stles to Swing components. Sweet! - 01/Feb/09 Griffon: Groovy & Scala working together
The beginnings of the Griffon Scala plugin. This post exploits the ideas of #1 and puts them into practice. - 31/Jul/09 Griffon: Clojure powered fractal
Demonstrates the polyglot capabilities of a Griffon application that displays a fractal created by Clojure code.
Categories: Blogs
Griffon: threading management
Right after Griffon 0.0 was released I made a post on the threading options it exposed. To recap, you can use the following methods on any View or Controller
This class provides the same behavior as the previous threading facilities but with the added advantage that it is toolkit aware, meaning it will use the proper threading facilities as required by the running toolkit. These are the main methods you will find on this class
Calling these methods from another class requires you to access the singleton instance of the UIThreadhelper, in other words you need to write something like
In the upcoming 0.3.2 release you'll be able to call these methods inside the life cycle scripts using the shorthand notation, no need to use UIThreadHelper.instance as a prefix. It is still undecided if a functional equivalent to SwingWorker will be added to the threading options or not, at the moment the only abstraction around that class is SwingXBuilder's withWorker() node.
You will find more information about threading in Griffon by browsing the Griffon Guide.
Keep on Groovying!
- edt {} - makes a synchronous call inside the EDT.
- doLater {} - makes an asynchronous call inside the EDT.
- doOutside {} - executes code outside the EDT.
This class provides the same behavior as the previous threading facilities but with the added advantage that it is toolkit aware, meaning it will use the proper threading facilities as required by the running toolkit. These are the main methods you will find on this class
- execSync {} - makes a synchronous call inside the UI thread.
- execAsync {} - makes an asynchronous call inside the UI thread.
- execOutside {} - executes code outside the UI thread.
- isUIThread() - queries if the current thread is the UI thread.
- execFuture {} - schedules the code on an ExecutorService and returns a Future.
Calling these methods from another class requires you to access the singleton instance of the UIThreadhelper, in other words you need to write something like
UIThreadHelper.instance.execSync { /* your code */ }In the upcoming 0.3.2 release you'll be able to call these methods inside the life cycle scripts using the shorthand notation, no need to use UIThreadHelper.instance as a prefix. It is still undecided if a functional equivalent to SwingWorker will be added to the threading options or not, at the moment the only abstraction around that class is SwingXBuilder's withWorker() node.
You will find more information about threading in Griffon by browsing the Griffon Guide.
Keep on Groovying!
Categories: Blogs
Handling the shutdown sequence in a Griffon application
You might have heard that Griffon 0.3.1 has just been released, and with it comes a new feature: ShutdownHandlers.
I know what you're thinking, executing code at application shutdown is nothing new, as a matter of fact there were 3 other ways to do it before this feature was added to Griffon. Let's review all of them in complexity order.
Shutdown life cycle script This is the first option that was added to Griffon back in release 0.0 (September 10th 2008 for those keeping count). This script will be called as part of the application's life cycle (inspired by JSR 296 Swing Application Framework), and it's always guaranteed to be executed inside the UI Thread. This script is a single point of entry (good) but it does not allow other artifacts to execute code at shutdown (bad) unless you call them explicitly on that script.
Application event handlers Then came application events at a later release (0.1 to be precise); they revolutionized how artifacts interact with each other. An application will send a ShutdownStart event when the shutdown sequence is initiated. You have the option to register an application event handler at any time; as a matter of fact almost of any type too (supported types are: Script, Map, Closure and beans). Controllers happen to be application event listeners by default, meaning that the following code is valid
class SampleController { def onShutdownStart = { app -> // do something at shutdown } }Application event handlers are guaranteed to be called outside of the UI thread always.
GriffonApplication subclass I almost decided to not write about this option as it is not for the faint of heart. Actually it is not that bad as it sounds, it's just that creating a GriffonApplication subclass is rarely needed. But if you do, then you have the option to override the shutdown() method.
All these options allow you to execute code while the shutdown sequence is in process, however none of them let you abort the sequence (unless you go with the subclass option, but why complicate yourself?).
Enter the ShutdownHandler interface.
ShutdownHandler This interface defines two handy methods
You will find more info on these features and other at the Griffon Guide.
Keep on Groovying!
I know what you're thinking, executing code at application shutdown is nothing new, as a matter of fact there were 3 other ways to do it before this feature was added to Griffon. Let's review all of them in complexity order.
Shutdown life cycle script This is the first option that was added to Griffon back in release 0.0 (September 10th 2008 for those keeping count). This script will be called as part of the application's life cycle (inspired by JSR 296 Swing Application Framework), and it's always guaranteed to be executed inside the UI Thread. This script is a single point of entry (good) but it does not allow other artifacts to execute code at shutdown (bad) unless you call them explicitly on that script.
Application event handlers Then came application events at a later release (0.1 to be precise); they revolutionized how artifacts interact with each other. An application will send a ShutdownStart event when the shutdown sequence is initiated. You have the option to register an application event handler at any time; as a matter of fact almost of any type too (supported types are: Script, Map, Closure and beans). Controllers happen to be application event listeners by default, meaning that the following code is valid
class SampleController { def onShutdownStart = { app -> // do something at shutdown } }Application event handlers are guaranteed to be called outside of the UI thread always.
GriffonApplication subclass I almost decided to not write about this option as it is not for the faint of heart. Actually it is not that bad as it sounds, it's just that creating a GriffonApplication subclass is rarely needed. But if you do, then you have the option to override the shutdown() method.
All these options allow you to execute code while the shutdown sequence is in process, however none of them let you abort the sequence (unless you go with the subclass option, but why complicate yourself?).
Enter the ShutdownHandler interface.
ShutdownHandler This interface defines two handy methods
- boolean canShutdown(GriffonApplication app) - informs the application that the shutdown sequence must be aborted if the return value is false.
- void onShutdown(GriffonApplication app) - executes the code as part of the shutdown sequence.
You will find more info on these features and other at the Griffon Guide.
Keep on Groovying!
Categories: Blogs
Griffon 0.3.1 released at Gr8conf
The latest version of the Griffon framework (0.3.1) was released last Wednesday live on stage at Gr8conf Copenhagen! You'll find a couple of new features and a handful of bugfixes, but perhaps most importantly, the immediate availability of the Griffon Guide.
The guide is still a work in progress, however it contains enough information to get you going. You'll find the guide and the API docs on every Griffon distribution too.
On to the features, the first one allows you to abort the shutdown sequence if needed, via a new type of listener (ShutdownHandler) that can be registered with the application. The second feature gives you more information about the application, this time it's the current running mode (joins the existing application metadata and environment features).
Another interesting tidbit about what happened at Gr8conf, the Hackergarten held its third meeting (and the first one outside of Basel) with close to 40 people this time! We broke into several teams, contributions were made to Groovy, Grails, Griffon and Gradle. Regarding Griffon, the team managed to write 3 GDSL files that provide code suggestions for Swing nodes on views, threading and MVC members (don't forget to check the Griffon Guide to learn more about those methods!). Big thanks to Kasper Fock and David Askirk for initiating the GDSL work and making most of the contribution.
Many thanks to the Gr8conf organizers, their sponsors, speakers, attendees and Copenhagen, it was a blast! Let's do it again next year!
Keep on Groovying!
Categories: Blogs
A small improvement to GroovyConsole
If you're a Mac user you've probably noticed that running a Java based application results in a default icon being placed in the dock. Groovy's console application is no exception, as the following pic bears witness
However, fixing this issue is simple; you just need to add a JVM option like the following one:
Keep on Groovying!
However, fixing this issue is simple; you just need to add a JVM option like the following one:
-Xdock:icon=/path/to/your/icons.icnsWhere can this option be added you ask? Why yes, here is how you can do it:
- Go to $GROOVY_HOME/bin
- Edit startGroov
- Search for JAVA_OPTS and Darwin. You'll find a line that looks like this
if $darwin; then JAVA_OPTS="$JAVA_OPTS -Xdock:name=$GROOVY_APP_NAME" fi - Add the -Xdock:icon entry to that line et voilĂ !
Keep on Groovying!
Categories: Blogs
Hackergarten #2 + Griffon
The second installment of the Hackergarten just took place this Friday, an excellent way to end the month and a working week if I may add. What is Hackergarten you ask? In brief, a group of people like you and me that come together to tackle a problem by hacking together. The first Hackergarten consisted of 8 people. Together they created an announce plugin for Gradle and submitted if that very night. I've been told that the plugin has been rolled into the upcoming 0.9 release, i.e. open source development rocks!
The second night wast Griffon night; we came together again to hack some Griffon plugins. Here's a summary of the whole experience in numbers
I'm also open to pair up and hack around a few hours with anybody that is interested in making plugins for Griffon and/or Grails; if you see me at any of these conferences then let's talk and code
Keep on Groovying!
The second night wast Griffon night; we came together again to hack some Griffon plugins. Here's a summary of the whole experience in numbers
- 10 people joined the fray
- 5 1/2 hours of fun
- 4 teams worked shoulder to shoulder to produce 4 plugins
- 3 plugins were released:
- The 4th plugin (DockingFrames) required a bit more of work than expected, however the team will be making a release soon.
- 8 pizzas gratuitously donated by our sponsor
- 3 bags of chips
- 1 bottle of red wine
- Too many beers to keep count
- 1 amazing sponsor (Canoo). Not only did they pay for the food and drinks, they also lend us the space and network. Thank you!
I'm also open to pair up and hack around a few hours with anybody that is interested in making plugins for Griffon and/or Grails; if you see me at any of these conferences then let's talk and code
Keep on Groovying!
Categories: Blogs
Curious about Groovy and Eclipse?
If so (and if you have the time) then please consider the following webminar by yours truly: Groovy for Java Developers. The event date & time is May 11th at 3pm GMT. Here's the quick abstractGroovy is a dynamic language that runs on top of the JVM, providing modern features to Java developers today, as Groovy has the best integration with the Java platform and language so far. In this webinar you will learn how Groovy can help you in your daily Java development using the Eclipse Groovy plugin v2.
Basic knowledge of dynamic and scripting languages such as Ruby, Perl, Python or JavaScript is desired for registrants as it will help them grasp concepts common to all those languages and Groovy.
I might not be wearing my pajamas like Dave did recently but you'll never know
Keep on Groovying!
Keep on Groovying!
Categories: Blogs
Upcoming Groovy/Griffon talks
It's been a while since I last blogged here and that's because of a good reason: just relocated to Switzerland (Basel actually) to join an incredible team! There so great I can actually spend some time out of the office to attend a few conferences and local events, along side fellow Groovy committer and colleague Hamlet D'arcy:
Keep on Groovying
- May 5 - jax.de - Flying with Griffon, Polyglot Programming in the JVM
- May 14 - Geecon - Flying with Griffon
- May 18 - Gr8conf - Flying with Griffon
- June 8-9 - Epicenter - Flying with Griffon, Polyglot Programming in the JVM
- June 24 - Karlsruher Entwicklertag - Flying with Griffon
Keep on Groovying
Categories: Blogs