Edit: I've moved this technology-related post to my new blog here.

Our situation: our build server uses Ant to automatically get the latest versions of the source files, build the application and deploy it.  A build number is updated in a properties file, but we lost the ability to check that file back into source control. (no write access for build user to source control server). This means the build number, say 500, is always incremented to 501, packaged into the war file, and sent out on the server.  The next night, another automated build kicks off and the properties file is retrieved with the current build number set at 500.  So the build process dutifully adds one to it, builds and packages the application and sends it off to the server with the build number at 501.  Again.

We needed a way to increment the build number to accurately reflect that a new build is generated and put out on the server - this helps not only to keep tabs on how many times we build the application, but the build number is also used as a random salt in the request parameters to prevent caching issues with browsers.

The workaround below will pseudo-increment the build number based on a "build epoch" - the same way time is kept on unix-like systems.  Note the enclosing target and project tags have been omitted.

    <property name="build.epoch"              value="20090101"/>

    <property name="todays.date"              value="${DSTAMP}"/>

    <propertyfile file="${file.version.properties}">

        <entry key="system.build.number"      value="${todays.date}"/>

        <entry key="system.build.number"      value="${build.epoch}" type="int" operation="-" pattern="0"/>

    </propertyfile>

In a nutshell: define the build epoch property as a certain date in the past.  The property file then sets the build number to today's date, and then immediately does a subtraction operation using the build epoch.  The dates (in yyyyMMDD format) are treated as integers and you get a different build number for each day.  It's not a true increment (on month boundaries the next number jumps up by about 70) and there is only per-day granularity, but... it works.

There must be tons of ways to avoid the whole problem in the first place, with so many opportunities to "do it the right way first".  While working on this setup, I noticed two thoughts flitting about in a certain echo chamber: "it's amazing"... and moments later: "it's asinine".  This is just how it turned out.

One of the new features of IntelliJ 7 is the support for Adobe's Flex language. You can enable this support by going to the project properties and adding a Flex facet, where you can specify the path to the Flex SDK. I set it up, but there was none of the expected IDE help for the ActionScript classes: no code-completion, class/type suggestions, not even syntax highlighting. Some Googling reveals a few more requirements: the JavaScript support plugin must be enabled (which it was) and the File Type needs to be registered for *.as files. In my setup, it was set to "Text files", adding the file pattern to JavaScript files (with a prompt asking if you'd like to reassign it from the existing text files setting -- very nice) and hitting OK then set off a somewhat lengthy parse of the ActionScript classes in the project. The Flex support is now working.

Kudos to Serge Baranov for the extremely quick support response and helpful guidance.

The things I do for bolded keywords...