Andres Almiray's complete blog can be found at: http://jroller.com/aalmiray
2012-03-14 15:14:00.0
This entry should be of particular interest to plugin authors (archetypes too!). In releases prior to 0.9.5 Griffon manages the source code of a plugin for you (this in an inherited trait from Grails in case you're wondering). When the release-plugin command was called the build would make sure that the plugin sources were uploaded to an SVN repository, then tagged with 2 particular tags (LATEST_RELEASE and RELEASE_X_Y_Z, where X_Y_Z matches the plugin's version). The default SVN repository was the Griffon central repository, which forced the developer to ask for developer membership and have his or her credentials validated in order to push a new release.
As time passed by and the number of plugins grew (in the case of Grails over +700!) releasing a plugin was quite a tedious task as SVN is not really that good when coping with multiple commits from different sources, not to mention that the central plugin metadata (kept as a huge XML file) had to be updated. The Grails developers then decided to add a new option for plugin releases: the ability to release only the zip file and let the developer choose where and how to store the source code -- still the metadata file had to be updated.
Back in Griffon the team recognized that they would eventually suffer the same troubles and decided to deal with the problem right away. Starting with Griffon 0.9.5 (latest release is 0.9.5-rc2) plugin releases no longer require the usage of SVN credentials as the code is never automatically stored by the build -- the Griffon build deals with the metadata in a different way, which will be the topic of another post later. But, as troublesome as SVN is the ability to commit and tag the latest release was a nice commodity. Could there be an option to have it back but use a different SCM other than SVN?
Enter the Git plugin.
This little guy can help plugin authors keep their source trees and releases in sync. Here's the typical workflow. Say you're working on a brand new plugin called awesome. The project was created with the following command
The next step would be to install the Git plugin like so
Third in the list is to initialize the repository. This can be done with standard Git means (assuming you have Git installed in your system) or by calling the git-init script provided by the Git plugin itself. Yup, that's right. If you paid attention to the output of the plugin install sequence you'll see a list of scripts that the plugin adds to the Griffon build. Here's the list again
OK, so we get a few scripts that mimic the Git commands, perfect. With this in mind you continue your work on the plugin; adding files to the Git index either by calling the native git command or by using the griffon git-add command, it's all the same. When the time comes to make a release you'll have to configure the default remote. Unfortunately this is an operation you have to perform using the native git command, there's no griffon script for it yet. Once this step is cleared you can release the plugin to any artifact repository for which you have clear access. The Griffon Central Repository located at http://artifacts.griffon-framework.org/ still requires you to signup and apply for developer membership, and it so happens to be configured as the default repository for releasing. So what now? Either you run a local copy of the portal (get it directly from Github -> https://github.com/griffon/griffon-artifact-portal) or use a local artifact repository (explained at this link). We'll assume the default local repository, aptly named griffon-local.
Calling the release-plugin command will trigger a chain of events after the release has been successfully uploaded to the repository: the git plugin will make a commit to the local git repository using the release message as the commit message; determine the tag to use based on the plugin's current version; finally pushing all changes to the default remote. So, with 0.1 as the current version number of the plugin the following command invocation
Results in a commit log whose message is "first release"; a tag named RELEASE_0_1 and all refs found in the default remote: origin. How is this possible? The Git plugin hooks into the Griffon build system and detects when a plugin or archetype project are released. Once the released has been successful it then calls the git-release script with a set of predefined arguments based on the release information.
You can of course call the individual commands at any time. As a matter of fact, this is what the git-release command does for you
The git plugin is Github friendly, as it understands remotes that make use of SSH such as Github. You can configure your Github credentials and SSH key passphrase in $USER_HOME/.griffon/settings.groovy like so
The sources for the git plugin are hosted at Github to (https://github.com/griffon/griffon-git-plugin), so if you find a missing feature and can't wait to get it from the Griffon team, then by all means fork it! And send us a pull request 
Keep on Groovying!
2012-03-12 05:32:00.0
Readers this blog may know that's possible to mix Groovy and Scala code in the same Griffon application (link 1, link 2, link 3). For a time using Scala within a Griffon application required you to still write MVC artifacts with either Groovy (the default) or Java, in a sense Scala support was confined to helper classes. But this has changed in the spirit of true polyglot programming.
Starting with the latest release (0.9.5-rc2, released last Friday) you can create a Griffon application where any of the base artifacts may be written using Scala. Here's how you can test it for yourself:
- Download a copy of Griffon 0.9.5-rc2 from the download page, install it and configure the Griffon command on your path.
- Install the Scala archetype.
- Create a new application, make sure to specify you want to use the scala archetype.
Executing step #2 results in a similar output like the following one
Good, we now have the Scala archetype installed in our Griffon distribution, in other words, it has become available and can be used in conjunction with the create-app command. Which is exactly what will do for step #3
This will initialize the application in such a way that the sources of the default MVC group will use Scala instead of Groovy, as witnessed by the following screenshot
If you inspect the contents of each file you'll find that they do in fact contain Scala code (a Java-ish kind of Scala code really). Notice also on the output of the create-app command that two plugins were installed, once of them is the Scala plugin.
You can run the application as you would do with any other Griffon application, just type griffon run-app and you're in business. From here on it's just a matter of changing the source code to make it behave as you want to. Any additional MVC groups that you may create will also use Scala as the source language. Remember that you can still mix & match Java and Groovy code anywhere in the application, but keep in mind the following rules until there's true interoperability between all compilers
- Java code in src/commons gets compiled first.
- Scala code in src/commons-scala gets compiled second.
- Java/Groovy code in griffon-app/* and src/main gets compiled next.
- finally, Scala code in griffon-app/* and src/main gets compiled at the last step.
If any Scala enthusiasts would like to help us make the Scala experience in Griffon even better then don't hesitate to ping us at the Griffon mailing lists or send us a message to @theaviary.
Keep on Groovying!
2012-02-24 09:30:00.0
Since the early days of Griffon it's possible to package an application in several packaging targets; the defaults are jar, zip, applet and webstart. Calling the package command with no arguments will automatically select these 4 targets for you.
But what if you desire a different set to be used when the package command is called without arguments? Since Griffon 0.9.5-rc1 you can specify the following flag in either $appHome/griffon-app/conf/BuildConfig.groovy or $USER_HOME/.griffon/settings.groovy, for example
Executing the package command will now package the application in zip and jar modes only.
If you happen to have the Installer plugin installed on your application you gain access to more packaging targets, like izpack, dmg, rpm and deb. These too can be added to the set of packaging targets you'd want to have executed by default.
Keep on Groovying!
2012-02-20 16:50:00.0
There are times when working with Griffon you'd like to know what's really happening during build process execution; for example, how much time does it take for a task to complete, or what are the different events you can react to using build event handlers.
There are two ways to know this. The first and easiest one is to define a value for the griffon.cli.verbose flag. This flag can be either set in the command line or written down in one of the two buildtime configuration files ($appHome/griffon-app/conf/BuildConfig.groovy or $USER_HOME/.griffon/settings.groovy). Take for example the invocation of the clean command right after a compilation step has been issued.
Now compare that to the output generated when the griffon.cli.verbose flag is enabled
Much different now. The first debug row tells us exactly which targets will be executed before the default one (defined by the Clean command) is called. For each target we can see when it began and finished, in milliseconds. What about the event name? Well it's a simple matter of capitalizing the target name and appending either Start or End, meaning that if you want to react to when the packaging has been cleaned then you must place an event handler named eventClearPackagingEnd on your event handler script (scripts/_Events.groovy). Bear in mind that the value specified at the command line for this flag will override any value set in the config files.
The second approach is to tweak the logging configuration available at buildtime. For this we'll need to edit $appName/griffon-app/conf/BuildConfig.groovy. Right at the end we'll find the default logging configuration in the form of a Log4j DSL. Modify it so that the package org.codehaus.griffon is set to trace, like this
Calling the clean command again after a compilation has been executed yields the following output
Now we can appreciate exactly the event names that the build will trigger. Notice that custom event handlers are registered during the execution of the loadEventHooks target, which means you can't react to events triggered prior to LoadEventHooksEnd.
Keep on Groovying!
2012-02-19 07:31:00.0
Welcome to a new series of posts regarding Tips & Tricks about Griffon.
The Griffon team decided to leave a late San Valentin present in the form of Griffon 0.9.5-rc1. This particular release includes plenty of updates to the build system and the command line tools. And here comes the first tip, which is enabled in the 0.9.5.x series: how can you tell which version of Griffon you're currently running? Moreover, how can you tell which Groovy version it relies upon?
The answer lies in using the --version (or -v) flag with the griffon command, and no arguments. For example, running the griffon command in my current setup with this flag turned on yields the following output
For plugin authors, this information is available at buildtime only as static properties found in the class org.codehaus.griffon.cli.GriffonEnvironment.
Keep on Groovying!