For an ActionScript project I am currently working on (and for future projects), we wanted to be able to include the ANT build number into our applications when we do development and production quality releases to clients. The added value in this is that it is extremely helpful if you are constently pushing releases. It saves time so that we can easily tell what version our clients are running on their development and production servers. This helps avoid unneeded debugging time making sure that the versions are correct. We also wanted this to happen automatically, or as much as possible, without the need for us to modify text files or add compiler variables.
Ok, lets get started! First, all of these instructions assumes you have a good knowledge in how ANT works. It also assumes you will be building an ActionScript or Flex project. In this case, we are going to be creating a custom ContextMenu but you can really do this for anything. This will allow anyone us to see the version numbers when they right click on our application.
Ok, so how is this done? Open up your build.properties file for the project and add the following lines:
project.major = 1
project.minor = 0
project.revision = 0
project.version = ${project.major}.${project.minor}.${project.revision}
The projet will act as our properties for figuring out the project major, minor and revision. These could probably be automated in some way but for now I am ok with manually setting these values since I will know when these versions change. We will also need to include a build number into our build so just add the following before anything else into your build file. Also note that if this file does not exist, ANT will create it for you so no need to concern yourself with what the contents are. Let ANT do the dirty work!
<buildnumber file="${basedir}/build/build.number" />
Next, we are going to want to copy our classes to a temporary directory so that we can modify them without harming the source. As you can see I have some temp.outdir and classes.dir properties
<target name="copyClasses" description="Creates a temporary directory where the code will be duplicated so we can modify and build without harming the original files">
<mkdir dir="${temp.outdir}" />
<copy todir="${temp.outdir}">
<fileset dir="${classes.dir}"/>
</copy>
</target>
Now that our classes are copied, we need to do a search on them for particular strings that we will end up replacing with the project version. In my case, I have a ContextMenu class which has a string value defined as “[PROJECT_VERSION_NUMBER]” so I do a regular expression replace in ANT to find that value and replace it.
<target name="projectversion" description="">
<replaceregexp match="[PROJECT_VERSION_NUMBER]" replace="${project.fullname} : ${project.version}.${build.number}" flags="gs">
<fileset dir="${temp.outdir}" includes="**/*.as"/>
</replaceregexp>
</target>
And that is it. Now we have our build number plus project version automatically showing up in our application.
Inserting keywords/variables in Subversion with auto-props
Spent a little time this week investing how to get keyword variables related to our Subversion repositories (version, last modified by, date, etc) automatically inserted into our code when we commit. My end goal was to have our code looking like the sample below with an initial comment header including our SVN information:
/** * ------------------------------------------------------------ * Copyright (c) 2010 Some Company. * This software is the proprietary information of Some Company * All Right Reserved. * ------------------------------------------------------------ * * SVN revision information: * @version $Revision: 82 $: * @author $Author: kris $: * @date $Date: 2010-07-10 08:36:02 +0200 (Sat, 10 Jul 2010) $: */ package com.somecompany.common.somepackage { import flash.display.MovieClip; /** * SomeClass description * * @author krisrange */ public function SomeClass extends MovieClip { /** * Constructor */ public function SomeClass() { super(); } } }As you can see, the SVN revision version, last modified author and last modified date show up in our headers. This is really important as a developer can look at the header and quickly know who last modified the file and who to talk to in case the initial author of the file may not be the developer who last updated functionality.
I will be writing this from the perspective of working on MacOS but most of this information is transferrable directly to a Windows machine except a few things like directory structures.
We need to make sure that files are setup to have their properties changed. The best thing to do is to change this globally for new files/repositories and then go back into any previous projects you have worked on and recursively loop through and add this functionality.
Modifying the Global Setting:
On MacOS, go into your home directory and open the “Config” file that lives in the hidden folder “.subversion”. Once you have this text file opened, uncomment the “enable_auto_props” variable in the “[miscellany]” section and set it’s value to “yes”. Then add the file types you would like include in the “[auto-props]” section with the value of “svn:keywords=Date Revision Author Id”. See sample below where I’ve set auto_props to modify all *.as and *.mxml files:
Modifying Previous Projects
In order for previous projects to gain access to this information, we need to set the properties on all the files we have already committed to set the properties on themselves when they are committed into our repositories. To do this, just type the following command for every file type that you want to have auto_props enabled for.
find * -type f -name '*.as' -exec svn propset svn:keywords "Date Revision Author Id" {} \;Getting the Values to Show Up
After that is all setup, just insert the values in your document based on the corresponding ID. So for example, if you wanted to insert the Last Modified Author, insert it like below and SVN will replace the content inbetween the word “Author” and “$:” with the actual value:
For more information on what keywords/properties are available, there is good documentation from Subversion.