Hi Chris, I actually started out by having a boolean for this, but then I noticed in the source code that there was one other return code that was already ignored specifically on Linux (code 139) without any explanation, so I thought that it would be nice to consolidate and leave this decision to the user, so the code base wouldn't have to be updated all the time (and as a next step remove the hard coded case 139 from the switch).
Regarding the Linux-only mode, I agree that it seems a little inconsequent. My motivation behind this was 1) your first reply to this thread, and 2) If the same project is built in different environments, we haven't seen a use case yet where it would make sense to ignore error codes in other OSes than Linux, so basically I didn't want the Linux users to hide real errors from users on other environments by added this parameter to the pom. I'm open though to change this in any direction. /Andreas Christofer Dutz wrote > I just had a look at your changes. > Are there more than one code the flashplayer returns? I thought it would > just be a return code 1? > > In that case I would favor a ... let's call it "boolean solution" ... sort > of like. "linuxFlashPlayerQuirksModeEnabled" or something like that. Just > a small sidehint on the HTML quirks mode ;-) > > Having to define a list of ignorable return-codes sort of feels > inconsequent. The other option would be to allow this on any operating > system as I see no reason for having such a configuration Option just on > linux. If I for example think about IntelliJ it would pick up the new > property "flashplayerReturnCodesToIgnore" and offer that to the user as an > option. He could be surprised why this only works on linux. > > What do you think? I'm sort of asking anyone interested in contributing to > this discussion. > > Chris -- View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Flexmojos-flexunit-testing-on-headless-Ubuntu-14-04-tp7894p7960.html Sent from the Apache Flex Users mailing list archive at Nabble.com.
