I forgot to mention that we are using the Flex 3.2 SDK level, which is not clear from the console output.
I just re-tried with 4.1 RC1, and get a little farther:
[com.djte.library:flexunit] Validating task attributes ...
[com.djte.library:flexunit] Generating default values ...
[com.djte.library:flexunit] Using default working dir [C:\EclipseWorkspace3.5\report.renderer_tests_2\Source\Flex]
[com.djte.library:flexunit] Using the following settings for the test run:
[com.djte.library:flexunit] FLEX_HOME: [C:\iFABS_DE\dev\vert-d3flxcmn24\204184.108.40.20600926233508_d3flxcmn24]
[com.djte.library:flexunit] haltonfailure: [false]
[com.djte.library:flexunit] headless: [false]
[com.djte.library:flexunit] display: 
[com.djte.library:flexunit] localTrusted: [true]
[com.djte.library:flexunit] player: [air]
[com.djte.library:flexunit] port: 
[com.djte.library:flexunit] swf: [C:\EclipseWorkspace3.5\report.renderer_tests_2\build\report.renderer.tests.unit.swf]
[com.djte.library:flexunit] timeout: [1800000ms]
[com.djte.library:flexunit] toDir: [C:\EclipseWorkspace3.5\report.renderer_tests_2\build\reports\xml]
[com.djte.library:flexunit] Setting up server process ...
[com.djte.library:flexunit] Starting server ...
[com.djte.library:flexunit] Opening server socket on port .
[com.djte.library:flexunit] Waiting for client connection ...
[com.djte.library:flexunit] Found AIR version: 1.5
[com.djte.library:flexunit] Created application descriptor at [C:\EclipseWorkspace3.5\report.renderer_tests_2\build\flexUnitDescriptor.xml]
[com.djte.library:flexunit] Executing 'C:\iFABS_DE\dev\vert-d3flxcmn24\204220.127.116.1100926233508_d3flxcmn24\bin\adl.exe' with arguments:
[com.djte.library:flexunit] The ' characters around the executable and arguments are
[com.djte.library:flexunit] not part of the command.
I see now that the Air version is evidently coming from the Flex SDK being used, since the adl.exe being launched is underneath my Flex SDK (C:\iFABS_DE...). So that seems OK.
The problem now is that nothing happens after this point. In the past, I saw the test runner GUI pop up, run the tests, and then close. Now, no runner appears to open/start. The process just hangs until I kill it.
Another update... I am not sure if this is the right way to proceed, but I attempted to run the adl command manually from a Command Prompt so that I could see what was happening. Here is what I see:
Adobe AIR could not be found.
Use "-runtime <dir>" to specify the location of the runtime.
You can download the latest version of the runtime
So, my guess is that the <flexunit> task does not realize that Air did not launch, and is waiting on its socket for data, but none ever comes. Hence the hang...
So, how does adl.exe normally find the AIR installation (which apparently is needed)?
OK, so I guess I will try to explain why my Flex SDK looks so weird. We have made modifications/extensions to the 3.2 SDK, and our build process uses ivy to perform a resolve to obtain the correct Flex SDK (with our mods) at execution time. This SDK is downloaded and stored under the \iFABS_DE\... folder in a specific versioned folder. Next, mxmlc is invoked from this SDK to perform the build of the tests. Then lastly, <flexunit> ant task is invoked to run the tests. I mention all this in case it matters.
For the record, I am not the writer of the tests. I am simply the one tasked with running the tests in a CI test system. So, please pardon my apparent ignorance of Air and Flash player configuration, etc.
1 person found this helpful
@Trevor - Still catching up on your posts, but you are correct, the default behavior to launch an AIR version of a test runner is using the adl command found in the SDK in your Flex home. As of 4.1, we included the ability to run a specific command for a SWF if needed using the "command" attribute on the flexunit task. If you have the AIR SDK installed in a location separate from your standard Flex SDK, use adl.exe from that particular SDK to run your test SWF. Keep in mind also, when running an AIR-based test runner, 4.1 only supports running the SWF, not a specific app descriptor file.
I'll dig into your posts more and try to get back with you later tonight. HTH in the interim.
NOTE: This approach may actually generate a bug since the Ant task generates the app descriptor using adt in the default FLEX_SDK directory. If the above doesn't work out, try creating an SDK which is a combination of Flex 3.2 and the version of the AIR SDK you want to use and using that as your Flex home.
@Trevor - Based on the error you received re: no AIR runtime found, I tried running adl by itself on my Mac and the error I received was "application descriptor file not specified". There is probably some hook between the AIR runtime and adl that needs to exist for ADL to launch. That being the case, since the Ant task doesn't let you decide how to call ADL, if you find that calling "adl.exe -runtime <air_runtime_dir> <generated_descriptor_xml>" works, then your setup is too custom for the current Ant task implementation.
My suggestion would be to try and find a way to link the AIR runtime with the the AIR SDK via the OS (maybe reinstalling the runtime). Even if you can assemble a custom SDK (based on my previous suggestion), you'll probably still have the runtime linking issue. In 4.2 I hope to add a hook to specify a custom app descriptor for the test run, but if others find they're running into this issue, I'll look into adding ways to specify default arguments to custom commands as well.
HTH. Let us know how it goes.
Thanks for your responses, Brian!
Yes, I think I see the immediate problem. The problem is that there is no Air runtime in our customized Flex SDK (based on 3.2), even though it appears to have the Air compile libraries. I had been attempting to use this custom SDK to run FlexUnit with, and I think that needs to change.
Why was I doing this?
Well, I had tripped over some problems with 4.1 earlier on when I attempted to run it without having FLEX_HOME set in the environment. So, now I have been setting FLEX_HOME programmatically in my code before calling the <flexunit> task. And I had figured that it would be a good idea to set FLEX_HOME to the same SDK that the tests had been built with, i.e. our customized one. Now I am thinking that this is not necessary, since our end users will never have access to this SDK. I now think that I should be able to install a new stock Adobe Flex SDK on my CI server, install the Air runtime into it, and then use that location when I set FLEX_HOME. Is that how others are doing it? If anyone could validate this approach, I would be grateful.
One question that arises in my mind now: How does the Air runtime get into the Flex SDK? I have installed the Air runtime using the installer from Adobe some time ago, so I am not quite sure what all that did. I assume the Air installer finds all the Flex SDKs on your machine and inserts the runtime in each location appropriately? Again, pardon my ignorance...
I have just tried out the above idea, i.e. setting FLEX_HOME to a different SDK that has Air runtime, and the <flexunit> task worked when I ran it! An Air window opened, the tests ran, and reports were generated. So, it would appear my problem is solved! Cool beans!
Brian, you made some comments about another possible issue with the "custom app descriptor". I am not sure if that applies to me or not. How would I know whether or not we need that support? Again, I know it would help if I was the developer who had actually written the Flex tests, but I am not...
Anyway, I hope this thread helps other folks who are having similar issues. I am going to reinstall a fresh Adobe SDK and the Air installer on a clean machine next, and see if the tests will run there.
Before ending this thread, I do want to point out that the ant task might have need of improvement in the case in which the user attempts to run the air "player" but the Air runtime is not setup in the SDK. On Windows, the ant process simply hung at this point, apparently thinking that the launch of the player had been successful, but in reality, the message about the air runtime being not found had occurred. It might be nice if it exited gracefully with a warning message instead of hanging. Just a suggestion...
Brian, as always, thanks again for your help with this issue.You guys are doing a great job with this project. Please keep it up!
@Trevor - Glad to hear things worked out. Error messages could definitely be better, so I've added that to my list to improve in 4.2 along with your example.
As far as the AIR runtime installation goes, I typically just use the installers that Adobe puts out on Windows, Mac, and Linux. I believe ADL uses whatever runtime is installed to integrate with the OS, but runs the SWF in the context of the version of the AIR SDK that it is associated with. Stock AIR SDKs come with the Flex SDK; based on the version of the Flex SDK that will determine the version of the AIR SDK that is included (e.g. - Flex SDK 4.1 comes with AIR SDK 2.0). It is possible to mix and match SDKs (e.g. - Flex SDK 3.2 with AIR SDK 2.0) from what I've seen people doing on the forums, but I've never experimented with this myself.
With respect to the app descriptor, when you create an AIR bundle or use ADL, you have to create an application descriptor file (typically generated by your IDE). This XML descriptor file describes config options for the AIR runtime best I can tell. Right now the flexunit Ant task generates that app descriptor for you so it has more granular control over the launching of ADL as well as to make it easier for folks who just want to gen a SWF. Some people want to use their own XML descriptor due to settings specific to their application that aren't captured by the generated descriptor from the Ant task. If you go to run your test suite and find that AIR specific tests are failing due to the descriptor, then this feature would probably be useful.
HTH and thanks for sharing your work with the group.
Thanks - this helps to de-mystify some of these questions for me. I am seeing some failures in the suite, but most appear to be genuine failures and not related to the app descriptor.
By the way...
I wanted to update this thread for anyone else reading it...
I was able to run my AIR based FlexUnit tests on a clean machine simply by installing a stock Adobe Flex SDK and then setting FLEX_HOME in my ant script to the location where I unzipped the package. I did not need to run the AIR installer, as had been previously mentioned in this thread. It seems that as long as the "runtimes/air" folder is populated in the SDK, you are good to go!
Thanx, for the last addition!
I had a similar problem and apparently using a flex 3.5.0 SDK without the runtimes dir.
I'm still puzzled how i got that SDK cause by default flex 3.5.0 sdk has air 1.5,right?
@Arnoud - You may have downloaded the Open Source SDK instead of the Adobe Flex SDK; I think AIR may not be included in the Open Source download but I'm not positive. I'd verify it for you, but opensource.adobe.com is still down for week 2