The new Ant Project Generator creates an Ant project for an FDT launch configuration which can be used independently of FDT or Eclipse. These generated Ant projects can be used for build servers, continuous integration servers or in larger build pipes.

A typical use case is to run tests on a continuous integration server. The following example shows how an Ant project could be generated to run tests.

The structure of the example project is this:

A test launch configuration has been created to run all test class with prefix Test:

This is the used test launch configuration: The new button opens the new Ant Project Generator dialog.

The new Ant Project Generator dialog: In this dialog you can define how the Ant project will be created. Most of the time the default options are fine. Option changes are immediately shown in the preview so you can check which options fit your needs. The default output directory is the name of launch configuration prefixed with ant- inside the project. After hitting button Generate the generator will create four files as summarized in the dialog message at the top:

• Ant project file build.xml (shown in the preview)This file contains all ant targets. It compiles and bundles the resulting SWF for testing, starts the test run, and creates the junit test report.
• Build properties file build.propertiesIn this file properties are stored. Usually sdk, workspace and project locations You may need to adapt this file manually in different environment.
• ActionScript test runner src/TestRunner.asThe test runner contains test class references to setup and run FlexUnit properly. You may need to adapt this file manually to add new test classes.
• FlexUnit ant task library flexUnitTasks-4.2.0.jar provides FlexUnit ant task.The FlexUnit ant task is used inside build.xml to start the test SWF. This ant task also generates a FlexUnit test results.

This dialog shows the successful end of the generation:

The generated Ant project has this structure:

The generated Ant project file build.xml in more detail: The default target has the name of the launch configuration (WebDemo-Tests).

The target WebDemo-Tests invokes a java task to execute the ActionScript compiler (the task is presented collapsed). Thereafter the second target FlexUnit-WebDemo-Tests is called. This target creates the test results directory, defines the FlexUnit ant task and executes it. Afterwards a junit report is created using the FlexUnit test results.

In case a launch configuration refers to other launch configurations (via launcher chain) for all these launch configurations separate Ant targets and appropriate calls are generated inside build.xml. The generation process recurses through all launch configurations.

Also the compiler java task uses properties to avoid hard binding: The sdk property is used to refer to the compiler inside mxmlc.jar and the framework SWCs. The main file of this compilation is the test runner TestRunner.as inside the Ant project.

The test runner contains a list to all test classes for execution during the test run: If you add test classes later you may need to add these classes to the list in this file so that the new test classes are also taken into account.

Properties used inside the Ant project are declared by this properties file: It contains properties for workspace, project, SDK and Flash Player. This file may need to be adapted to allow the Ant project to run in different environment like a continuous integration server. If no Flash Player is defined in FDT preferences the last line is skipped and you have to add the property flashplayer manually.

To test the Ant project we can launch it here:Make sure that Ant starts in a separate JRE to avoid problems.

The console log of the Ant project launch shows all executed targets: The first Ant target compiled the testSrc.swf and the second target started the flexunit task, which invoked the Flash Player for testSrc.swf. In the last line of flexunit task a test run summary is presented. In total four tests has been recognized. One test of class com.powerflasher.SampleApp.TestWebDemo was skipped and the other one has been executed. For class com.powerflasher.SampleApp.TestSpecialPart both tests has been executed. The test results are place inside the testResults folder below the Ant project directory. The junitreport task uses these test results to create a html test report page.

The html test report page:

Assume you recognize a new test class has to be added into the test run. So you have this new test class TestDemoPart:

You could consider to recreate the Ant project completely. But this may remove all manual adaption you may have applied to the build.xml or build.properties. But this is not necessary.

The Ant Project Generator has options to skip files from writing: Only the test runner file will be written all other files are skipped.

After generation the test runner is modified to: A a reference to the new test class TestDemoPart has been added.

Ant Project Generator for AIR

The Ant Project Generator works also for AIR projects. The following example is an Android project with this project structure:

The used launch configuration to start the Android project:

The Ant Project Generator for the Android launch configuration: The build.xml will contain an extra target to start the AIR Debug Launcher (adl). The target is called after the Android project has been build. Currently only AIR launch configurations starting the AIR application on desktop are fully supported. For AIR launch configurations starting on device the extra target is not generated and an Ant echo message with a warning is included instead.

Inside the FDT AIR Properties the Ant Project Generator is also available:

The Ant Project Generator Dialog for deploy uses the preparation launch configuration: Instead of an AIR debug launcher target the build.xml will contain the deploy target for the Android project. The deploy credentials are stored in a credential properties file in the Ant project folder. To use the generated Ant project in a build server for AIR deploy you may need to adjust the properties file to match the build server environment. Often the credential properties file has to be adjusted to refer to the deploy credentials instead of the development credentials.