Building Flex projects in ant/nant

Question

We have a recurring problem at my company with build breaks in our Flex projects. The problem primarily occurs because the build that the developers do on their local machines is fundamentally different from the build that occurs on the build machine. The devs are building the projects using FlexBuilder/eclipse and the build machine is using the command line compilers. Inevitably, the {projectname}-config.xml and/or the batch file that runs the build get out of sync with the project files used by eclipse, so the the build succeeds on the dev's machine, but fails on the build machine.

We started down the path of writing a utility program to convert FlexBuilder's project files into a {projectname}-config.xml file, but it's a) undocumented and b) a horrible hack.

I've looked into the -dump-config switch to get the config files, but this has a couple of problems: 1) The generated config file has absolute paths which doesn't work in our environment (some developers use macs, some windows machines), and 2) only works right when run from the IDE, so can't be build into the build process.

Tomorrow, we are going to discuss a couple of options, neither of which I'm terribly fond of:

a) add a post check-in event to Subversion to remove these absolute references, or b) add a pre-build process that removes the absolute reference.

I can't believe that we are the first group of developers to run across this issue, but I can't find any good solutions on Google. How have other groups dealt with this problem?

Answer 1

I found that one of the undocumented requirements for using ant with Flexbuilder was to have the varible FLEX_HOME set within your ant script. Typically within build.xml have the following:

<!– Module properties –>
<property environment=”env”/>
<property name=”build.dir” value=”build”/>
<property name=”swf.name” value=”MyProjectSwf”/>
<property name=”root.mxml” value=”Main.mxml”/>
<property name=”locale” value=”en_US”/>
<property name=”FLEX_HOME” value=”${env.FLEX_HOME}”/>

This may seem like a hassle but it is a far more reasonable approach to obtaining consistency across platforms and environments if you are using multiple platforms for your developers.

HTH

Answer 2

While not a solution to your specific problem, a workaround is to use a continuous integration server.

Using something like Cruise Control you can have an automated build kick off every time someone submits something to source control. Then if the build fails for any reason (including environment inconsistencies) it's up to the developer who broke it to fix it. You can configure it to send emails on failure/success in various ways.