Trying to set "continue.after.failing.tests" to false won't fail the build when a unit test fails while building a NetBeans Platform application.  The property can be set in the project's properties file, in the application's build file, or on the command line.

Initially it seemed like the order that files were imported was the culprit because "suite.xml" sets the property to true before the project's properties file is loaded.  Since Ant's properties are immutable setting the property in the project's properties file wouldn't do anything.

With that in mind, I thought setting the property to false on the command line or directly in "build.xml" (before "suite.xml" gets loaded) would work.  With some echos I could tell the property *was* set to false when the "-do-testng" task was executed, but the build still succeeded.

After reading the documentation for the fail task, it turns out that normally the "unless" attribute causes the build to fail only "if a property of the given name doesn't exist in the current project."  Therefore even if it's set to false the build still won't fail.  (See https://ant.apache.org/manual/properties.html#if+unless.)

I'm not sure what a good resolution would be.

If "suite.xml" was changed to not set the property then the default behavior would change.  Builds that previously succeeded would fail until they were updated to define "continue.after.failing.tests" explicitly.

Changing the fail tasks to expand the property would work, but only for Ant 1.8+ and it looks like the build script only requires 1.7.1 right now.

Perhaps the best solution would be to use the condition task:

    condition property="do.testng.fail.build"
      and
        isset property="tests.failed"
        or
          not
            isset property="continue.after.failing.tests"
          isfalse value="${continue.after.failing.tests}"
    fail if="do.testng.fail.build"

Notes:

 - Checking if the value is unset is required when modules are built directly since "suite.xml" isn't included then (of course, it's also more robust that way)

 - This is just for the "-do-testng" target -- it would need to be done for JUnit and possibly elsewhere, too

 - I've tried to scope the property to make sure it doesn't conflict with anything else, but maybe someone that knows the whole build better could come up with something better

 - I didn't use XML because I didn't know what Bugzilla would do with it, if anything

 - Could the condition be simplified?