The error may be in validating the "task attributes".
I wanted to say that I have checked all the parameters being passed to the <flexunit> task, and all of them are valid - no "null" object references.
@trevorbutler - I implemented some tiered validation for task properties and elements for the new compilation features, so I just may have an equals on the wrong side or something. I'll dig into it this weekend to see what I can find out for ya. There is no reason the sample you've submitted should not work from what I can tell.
OK, a colleague worked with me (thanks, John!) to debug the problem a little further, and I think we found the fundamental problem. I wanted to post that info to save you some time...
Aside: One thing we did have to do was to rebuild the flexUnitTasks.jar to include debug information, since the binary in the 4.1 beta 2 package did not have debug=true. I'd suggest that we might want to change the build script to build the binaries with debug moving forward.
Back to the problem.
The NullPointerException is thrown in TaskConfiguration::validateSharedProperties(), when equals() is invoked. Here is the code snippet:
//if we can't find the FLEX_HOME and we're using ADL or compilation
if((flexHome == null || !flexHome.exists()) && (testRunConfiguration.getPlayer().equals("air") || shouldCompile()))
throw new BuildException("Please specify, or verify the location for, the FLEX_HOME property. "
+ "It is required when testing with 'air' as the player or when using the 'testSource' element. "
+ "It should point to the installation directory for a Flex SDK.");
In my case, I do not have a FLEX_HOME property set in Ant currently. I'll bet most folks have this set, so the logic would run differently for them. For my case, the (flexHome == null) check is true. That means that the testRunConfiguration.getPlayer().equals("air")check will occur next, and here is the problem. The "player" member is not set in the testRunConfiguration yet at this point, so testRunConfiguration.getPlayer() returns null. testRunConfiguration.setPlayer() is called in generateDefaults(). But generateDefaults() is not called until after validateSharedProperties() is called. So, if properties initialization could be improved here and I think this code will run more robustly.
I can work-around my issue temporarily by just setting a FLEX_HOME property in Ant. But I hope you will agree that the initialization issue with "player" still should be addressed. Would you like me to open a bug report, or is this thread enough?
1 person found this helpful
@Trevor - Thanks for digging through the source to help me figure out what was doing this to you. The FLEX_HOME property existing is a requirement to use the compilation support and the AIR support in 4.1. We have to locate the JARs needed to make certain decisions for code generation and need to know where the Flex SDK is to do so. The Flex SDK tasks have a similar requirement, so it doesn't doesn't feel like too much of a stretch to the team. That being said, I can definitely tweak the defaults generation to be more robust such that if you're using the SA FP and providing a SWF, there is no reason to require the FLEX_HOME property. I'll also move default generation around so that the configuration classes are populated correctly prior to the validation. Should be able to have a fix this weekend and out in the next RC for FU 4.1.
Good find man. Thanks for the help.
@Trevor - Ok, ended up being a much simpler fix than I thought. I've just switched the evaluation order for the player property so it now reads:
if((flexHome == null || !flexHome.exists()) && (new String("air").equals(testRunConfiguration.getPlayer()) || shouldCompile()))
Additionally, I've renamed generateDefaults to propagateSharedConfiguration() since it's a more appropriate to what the method is doing. I want to validate the configuration first to catch any strange inputs other than the defaults set at construction to report back to the user immediately and then push the shared config options to the compile and testrun configurations.
I believe this should fix the error you're experiencing. Look for the fix in my fork this weekend and in the flexunit master for RC1. Thanks again for the find.
Thanks, Brian. I appreciate your work on this, and look forward to giving it a try.