GradleFx: What's to come (short term)

In this post I'll give you an overview of the upcoming changes (short term) in GradleFx. As you'll notice the focus will be on improving what's already in GradleFx.

Next GradleFx release

So let's get started with the next release which is right around the corner. The two biggest changes will be:

• Better error and warning messages.
• Big improvements to the FlexUnit integration.

Better error and warning messages

Did you also got that nasty error when you didn't specify the FLEX_HOME environment variable when you first ran a GradleFx project? Well, you won't get that one anymore in the next version of GradleFx, including some other checks which will produce some more meaningful error and warning messages, like when you use a compiler property which is also being used by GradleFx.

FlexUnit improvements

Some major changes have been made to the FlexUnit integration. The configuration process has been greatly simplified. This is what you won't have to do anymore:

• Manually download FlexUnit
• Specify the name of the FlexUnit ant task
• Create a FlexUnit Runner mxml class
• Update the test cases in the FlexUnit Runner

These are now improved as follows:

• You have to define the FlexUnit ant task as a maven dependency (the artifact should be on Maven Central shortly), so no need anymore to manually download FlexUnit.
• The FlexRunner is now created automatically
• GradleFx will scan for classes ending with Test.as in your test source folder. This pattern can be changed by overriding the flexunit.includes and flexunit.excludes properties

So these changes greatly reduce the required configuration, which brings the FlexUnit integration to a quality level.

What will come after the upcoming GradleFx version?

The features that will be implemented after this upcoming GradleFx release will revolve around automatically downloading the Flex SDK and Flash executable (used for the unit tests). This is the last step to make a GradleFx build stand on its own without needing initial configuration by the end-user.

Automatic download of the Flex SDK

Right now you have to create a FLEX_HOME environment variable or specify the flexHome property which point to the Flex SDK installed on your machine. I want to improve this process by automatically downloading the Flex SDK and unzipping it to a directory which can be accessed by GradleFx. Now, how will this work? I've got the following idea in mind: Create a flexSdkUrl property to which you can specify the url to a Flex SDK zipfile, which you can specify like this:

flexSdkUrl = 'http://fpdownload.adobe.com/pub/flex/sdk/builds/flex4.5/flex_sdk_4.5.1.21328A.zip'

This will then download the Flex SDK, unzip it to a %USER_HOME%/gradlefx/sdks/flexsdk-x.x folder (which will be configurable) and which will be used by GradleFx to run the compiler etc.
Again a great improvement which follows the KISS principle (Keep It Simple, Stupid). This should allow a great deal of flexibility in which SDK you use and where you host it. You can even create your own custom SDK (e.g. with a different AIR version in it) and link to it.

Automatic download of the Flash executable

This will follow the same principle as the SDK download. You will be able to specify the Flash executable download url like this:

flashExecutableUrl = 'http://download.macromedia.com/pub/flashplayer/updaters/10/flashplayer_10_sa_debug.exe'

Then it will automatically download the executable and store it in a %USER_HOME%/gradlefx/flash/ directory, which will be used by GradleFx.

I hope this update gave you a clear view of what is coming up. There are of course a lot of other features on my list, but I first wanted to polish the existing features before implementing new ones (although some of these could be seen as new ones...)