Bill Barker wrote:
"Sander Temme" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
See: http://clarus.apache.org/junit/junit/gump_work/
build_junit_junit.html
And, this appears to be on MacOSX only, since both vmgump and gump.zones
show the junit entry as green in the logs.
It seems that a single test is failing because it expects a different
return value from a subprocess. No idea what would be different, no time
to investigate and I fear I lack applicable knowledge in the Java space.
Anyone know what could be happening and why?
Well, from the JUnit code, the subprocess is basically:
$JAVA_HOME/bin/java -cp . org.junit.runner.JUnitCore
org.junit.tests.JUnitCoreTest$Fail
That *should* end up calling System.exit(1), which in turn *should* cause
'java' to return a status code of 1 to the caller. I don't know OS/X enough
to have a guess as to which of these isn't happening.
-There is ongoing discourse in ant-dev about return codes and VMS,
because their notion of success and failure is different, but not
changes in the code, and it will not kick in for other platforms.
-I also know that on SYSV unix (AIX, HPUX), a return code like -1 can
get turned into 255, so you shouldn't check for an equals, just a
non-zero ret code.
However, macos is a BSD derivative, and no limitation on return codes to
byte length will turn a 1 into a 0, so something else may be going on
wrong here. I believe the java turning System.exit(1) into 1 is
something some of Ant's <exec> pr <java> tests should check for, and if
they dont, we can add a new test to do just that. That would help
isolate the problem.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
