The Griffon Trove: plugin source management

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
$ griffon create-plugin awesome The next step would be to install the Git plugin like so
$ cd awesome $ griffon install-plugin git 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
Plugin git-0.1 provides the following new scripts: -------------------------------------------------- griffon git-add griffon git-commit griffon git-ignore griffon git-init griffon git-push griffon git-release griffon git-status griffon git-tagOK, 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
$ griffon release-plugin --repository=griffon-local --message='"first release"'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
$ griffon git-commit --message='"first release"' $ griffon git-tag -f RELEASE_0_1 $ griffon git-push

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
git { author { name = 'Andres Almiray' email = 'aalmiray@yahoo.com' } repositories { origin { username = 'aalmiray' password = '*******' // oh, secret passphrase = '*******' // not telling } } }

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!