« Reading Flexcoders Again | Main | New Flex Blog by Al Manning »

Improving the Flex Ant Tasks

I've been looking at ways to improve some Ant Flex builds, and in the process I've added "arg" support to the Flex Ant tasks. I'll show how this can be done below, and I'll also share a bit about my investigation into speeding up Flex builds.

I wanted to convert some Ant builds to use the Flex Ant tasks, but it's painful to convert Ant targets that use "java". The problem is that all existing "java" calls will use command-line arguments, aka the "arg" element. The "arg" elements follow the command-line use of mxmlc and compc, and it's a different format than the Ant tasks.

In order to get the "arg" support, you'll have to do the building of the Ant tasks yourself. I could have just provided the jars here, but I don't have a clean copy locally. And it's good to have the source locally to know how to make more changes. Here's the steps:

1. Download the Flex 3 source.
2. Open the Ant tasks you want to alter. They're found in "modules/antTasks/src/flex/ant/".
3. Add the following line somewhere within prepareCommandline():
cmdl.addArguments(getCommandLine().getJavaCommand().getArguments());
4. Recompile the jar by running "ant" when in the directory "modules/antTasks". You'll have a new version of the Ant tasks at "lib/flexTasks.jar".

If anybody creates a version of the flexTasks.jar with just this change, I'll link to it here.

Why would you want to convert existing targets to use the Flex Ant tasks? I thought that the usual reason was to get wildcard support for compc arguments, but I don't see this feature in the documentation. In any case, Brightcove already had this support through some complicated Ant work. The reason I was looking into this was for some performance improvements.

I thought I could get some speedup by keeping a bit of shared state between compilations, and doing this required some Flex Ant task and compiler changes. I had forgotten, though, how much shared state is needed to really improve the performance. So although I started to convert over some of the Ant targets, in the end I left them all as "java" calls.

A better approach to getting some faster Ant builds is to use the compiler API in a set of new Ant tasks. If anybody has any Ant tasks out there for this, I'd be interested in using them. I know about the Maven support, but it looks to me like I need to create some Ant tasks myself to take advantage of the compiler API.

Comments (5)

Velo:

Yep, using compiler API flex-mojos was twice faster to compile flex-SDK.

Compile API show great results on modular projects, since you load JVM and compiler once, and not an extra JVM per module.


VELO

I found this page, which shows the 2x speedup. Very nice:

http://www.techper.net/2008/07/15/fast-flex-compilation-with-maven-israfil-or-flex-mojos/

The compiler API gives you more than just loading JVM/compiler. It allows a bunch of the compiler data to stay in memory to allow for incremental compilation. Time to try to create some Ant tasks.

I think the Flex community needs an Ant Task that will load up the compiler jar once and compile multiple modules with it.

The Flex Compiler Shell from Clement Wong almost does it, but only for Flex 2 because FCSH uses a compiler API class that was apparently removed in the 3.0 SDK. Clement Wong states this on his blog, and also I got FCSH to work with the 2.0 SDK, but not 3.0.

So it looks like Adobe have actually removed any hope of reusing an instance of the compiler over multiple modules...????

Cheers,

Ed.

Hi Brian,

I've just had a look at Paul Reilly's commits, and this one (http://www.adobeforums.com/webx/.59b63aee) includes a change to FCSH.java.

Is the Flex Compiler Shell back in for Flex 4?

Cheers,

Ed.

Hi Ed, I didn't realize that fcsh went away in Flex 3, so I don't know the answer to this. If you ask on the Flex SDK list (http://www.adobeforums.com/webx/.3c060fa3/), you're likely to get an answer.