Simon Gregory

A code validator was for a long time one of the tools missing from the ActionScript developers toolbox. Last year that changed and we can now benefit by keeping a robotic eye on our projects. One that helps improve style and consistency, and avoid complexity. Something even more important in team or distributed code environments. Hooking validation up to a continuous integration server is even better as the audit triggers automatically, problems get reported and graphed, and builds can be failed when maximum limits are breached – a clear signal that it’s time to review and refactor.

Joa Ebert was first to the market with AS3V and I quickly wired it up to run with TextMate. AS3V is 90% to 95% there, but still needs a couple of features. My guess is that Joa is now focusing on other things.

Since then Adobe have open sourced FlexPMD. After a couple of false starts I was able run the RC4 build against the codebase I was working with at the time. Even though we’d been through and fixed most of the 3,000 odd issues reported by AS3V, FlexPMD kicked out over 5,000 ‘violations’. The code had been worked on by around 20 developers over a 3 year period so it’s likely to be an extreme case, but still my advice is to use it from the start of a project.

For TextMate users the FlexPMD.tmbundle should help make the process easier. Installation and usage details are covered in the README. They boil down to using ⇧⌃v then selecting ‘Project’, ‘Document’ or ‘Show Report’.

Finally its worth saying that being pragmatic is a sensible option when working with validation tools. They aren’t a substitute for a good programmer. So blindly accepting the default ruleset and fixing everything won’t necessarily be productive. You can and should consider modifying the rules to get what suits you and your team, and there’s always going to be exceptions to the rule. Which is what //NO PMD is for.

Being a Ruby lover I’ve always intended on using Sprouts for project management. But when I was last looking for a solution you couldn’t easily specify which revision of a Flex SDK a project should be built with. This was something we needed to do. Access to the continuos integration box was limited which also caused problems, so we went with ant. I’ve been rolling out the same ant scripts and associated libraries into projects ever since. Code should be DRY, so why not your projects?

Minimalism in action

Maven has always been on the radar, but Flexmojos has made it all the more attractive to flash developers so there’s been more and more chatter about it recently. At work it’s been talked about for while, and after a sales pitch from Mischa, I’ve finally started to put it into action. So far it’s really cool, simple, clean, and consistent. The projects I’ve converted just end up with test and src directories. A lot of junk is gone, reduced to a few lines in a pom.xml file. They’re smaller and easier to understand. Just the kind of minimalism I like.

Getting an overview

Starting by understanding how Maven works is a sensible idea, for this try Maven:The Complete Reference. Then, for flex related tasks the Flexmojos site is a good source of information. Keeping an eye on the Flexmojos mailing list also helps.

Installing maven 2 + 3

Maven comes preinstalled on OS X so type mvn --version into the Terminal and you’re likely to see this:

Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_GB, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" 

This means you’re good to go with all versions of Flexmojos prior to 4.x but you’ll need to install Maven 3 if you need to use any of the features in 4, as I’m after AIR compilation, and ASDOC builds against Flex SDK 4 I needed to install the Maven 3 beta.

To start with download it, then unzip to /usr/local/apache-maven/apache-maven-3.0-beta-1. You’ll then need to edit your ~/.profile to include the following:

export M2_HOME=/usr/local/apache-maven/apache-maven-3.0-beta-1
M2="$M2_HOME/bin"
PATH="$M2:$PATH"
MAVEN_OPTS=-Xmx1024m

The last line isn’t necessary, but I added it to give Maven a little more memory to work with. The install notes also say you need to set JAVA_HOME. I didn’t find it necessary, but if you want to then finding out where JAVA_HOME is on a mac means running /usr/libexec/java_home (should be the same as what Maven’s just told you above) and adding the results to your ~/.profile. For me this was:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

Running tests also meant doing a little bit of work. If they don’t work for you then you may need to tell Flexmojos where to find your install of the standalone flash player. So going back to your ~/.profile you will need add the following:

PATH="$PATH:/Applications/Flash Player Debugger.app/Contents/MacOS/"

Then your pom file needs the following added to the flexmojos-maven-plugin configuration node.

<flashPlayerCommand>Flash Player Debugger</flashPlayerCommand>

There’s a full example of this here

Concluding with poms

Once installed maven is designed to automatically fetch all the resources it needs. This is done via configuring your pom files to reference the right artifacts so that maven can retrieve them. Where a dependency can’t be found online you have the opportunity to install it locally. So far I’ve used the documentation and found example files and have been reasonably productive. This example pom tests, compiles, validates and generates asdocs for a swc library I’m experimenting with. I’m looking to expand this to include swf + air compilation, and test coverage reports.

As Flexmojos 4.x is still under active development it can be tricky to get something to work as expected, you do need a little patience. But that is to be expected with alpha software. Version 3 doesn’t offer the full feature set I’d like so at the moment maven doesn’t feel like the complete solution. But as the source is now on github so maybe I can find some time to help out. Overall I’m totally sold on the concept and am looking forward to 4.x moving into stability.

Initially I set out with the aim to switch from Subversion to Git before there was an official plan from the TextMate crew. This has now changed, and all bundles that show Github activity are being removed from the TextMate svn repository. Which means that the official bundles I mirrored now have a duplicate Github mirror, and one that is more central for TextMate users and should be the root of all development. The Apache bundle was easy to sort, as there were no forks I could simply delete my copy. The Ant bundle wasn’t so straightforward.

Theoretically there’s no reason why two mirrored repositories couldn’t be used as each can be added as a remote. But because of their independent initialisation against the svn repo their histories aren’t identical this doesn’t work correctly in practice. Even though the file contents are identical at each commit git still recognises separate commits because git-svn appends unique metadata. So you end up with a lot of messy duplication in the history tree.

The fastest solution is to rebase one mirror into the other. Public rebasing isn’t the done thing as it’s bad practice to be changing the repository history when others could be working against it. However in this case we are looking to retire one history completely. I think, given that there’s only a little work in the forks, and the file content is the same it is the right solution.

So here are the steps I took to merge my mirror into the official one

• Forked and cloned the official bundle on github
• cd‘d to the root of the clone
• Added new remote using git remote add old-origin git@github.com:simongregory/ant-tmbundle.git
• Fetch the remote data git fetch old-origin
• Created old-master branch from the old-origin/master with git br old-master old-origin/master
• Checked out old-master git co old-master
• Rebased old-master onto master using git rebase master
• Switched back to master git co master
• Merged master with old-master git merge old-master
• Deleted the old-master branch git br -D old-master
• Created new sg branch git co -b sg
• Cherry picked the one commit I needed git cherry-pick 91f598
• Pushed the branch git push origin sg
• Removed the old-origin remote using git remote rm old-origin

Then to linked to the official TextMate remote using

• git remote add tm git@github.com:textmate/ant.tmbundle.git
• Fetched the remote data git fetch tm
• Checked master out git co master
• Synced master branches by pushing git push tm (only possible if you have write access)

One extra thing to note is the change from the old naming convention using a hyphen to a period.

There’s likely to be a better way of achieving this, but this is what worked for me. It won’t work if you have any private branches as you wouldn’t be able to pull them across. In this case I’d look at inverting the process and adding the new fork as a remote to the existing repository and merging from there.

I’ve just updated the ActionScript 3 Bundle to include an ASDoc language definition. This is essentially a scope change of Luke Daley’s JavaDoc language definition. The result is that the following scopes within the documentation blocks are brought under new colour jurisdictions.

keyword.other entity.name.tag punctuation.definition.tag

For me, using my favourite theme – Twilight – the extra colour where I was so used to seeing grey wasn’t working. To combat it, and get things greyscale again, I added 3 new theme elements and applied them to the following scopes:

comment.block.documentation keyword.other comment.block.documentation entity.name.tag comment.block.documentation punctuation.definition.tag

The results are the HelvectorLight.tmTheme which calms things down again.

Download

As a Flash developer who’s been working with Flex and ActionScript 3 since late last year I found I couldn’t settle down and use the Flex Builder Eclipse plug-in. Previously I had acquired the habit of editing ActionScript using TextMate and compiled using the lightning fast MTASC, and although there were alternatives (FDT, Sepy), I’ve always preferred the lightweight flexibility and crisp feel that TextMate has. As a result I’m responsible for TextMate’s ActionScript 3 and Flex bundles.

At the moment the bundles are in the review section of the TextMate Repository. Once installed the bundle help covers how to set up (primarily to download the flex sdk) and outlines the non-obvious commands.

The main highlights of the bundles are:

• MXMLC and FCSH Build Commands.
• Function, Tag, Import Auto Completion.
• ActionScript 3 and Flex documentation search.
• Drag and Drop of imports, includes, embed assets, css, xml.
• ASDoc Support.
• MXML Validation.
• Manifest Generation.
• Class and Component Templates.
• Flex Builder compatible project creation.
• Unused Import statement removal.
• Shortcut Key Super Class, Code Behind and Import file opening.

Thanks to the following people who have all had a hand, although they may not know it, in the creation of the bundles:

• Daniel Parnell
• Theo Hultberg
• Mark Llobrera
• Joachim
• ChromaticRain
• Thomas Aylott

For those of you who don’t use subversion the following zip’s can be downloaded, but they won’t necessarily be the latest version :

ActionScript 3 Bundle Flex Bundle