Thanks Meg, for the introduction.
Hello Steve,
My name is Powell Hazzard and I am one of the original OpenVMS
Java engineers. I have also worked other Open Source products like
Tomcat, Mozilla... I'm currently working with Meg regarding
understanding (and hopefully resolving) the Ant junit test failures on
OpenVMS.
Thank you for your comments regarding new "magic" OpenVMS
properties, believe me when I say that I completely understand your
comments. I also agree with your idea about a pluggable exit
interpreter in the future. I feel I should explain in detail as to why I
thought Ant needed an OpenVMS property and that I'm open to any
"guidance" you would like to offer.
I have observed that with most Open Source projects, zero is
treated as success and non-zero as failure (or as a special status
code). Whereas with most native OpenVMS scripts/executable the
low-order 3 bits of the returned status value represent the severity of
the status. Severity values range from 0 to 4, as shown in the following
table:
Value Severity
0 Warning
1 Success
2 Error
3 Information
4 Severe (fatal) error
While I was initially pleased to find the recent Ant changes
(not made by us here in OpenVMS engineering, BTW, which doesn't matter
at all) that support these values; after attempting run Ant's and
Jboss's junit tests on OpenVMS it became clear that we might have a
strong need for return statuses that matched the "Open source"
philosophy. This means some way to support two environments. One
environment that will support applications that expect the Open Source
success as zero, and one environment that will support VMS status codes.
As for my change to isFailure, we're happy to consider a different
implementation. You're right about Exec being used in lots of places.
Actually, Exec isn't the only place that exit codes are checked, and
therefore, whatever type of solution we settle on will need to address
other tasks that check return statuses as well. I have found in other
parts of the Ant source that there is code that checks the status return
values without using isFailure. I suppose one could consider these
checks a bug? If what you're suggesting is to add a method to some
utility package that would implement the status checking in one place
that all these different classes could call, then I could see that.
Here is a list of what I've found so far:
ExecuteWatchdogTest.java
assertEquals(0, process.exitValue());
ForkingSunRmic.java
return exe.getExitValue() == 0;
Exec.java
err = proc.exitValue();
if (err != 0) {
if (failOnError) {
In conclusion, I can see the need for the two types of behavior,
Open Source and Native OpenVMS. I fully believe that all Open Source
code should work the same regardless of platform; I feel the default for
Ant should be supporting the Open Source environment to promote 100%
compatibility even if a user written task doesn't call isFailure.
That's why I thought of using some kind of switch/property to control
the way the return value is interpreted.
I hope this explains things in sufficient detail to continue the
discussion.
Thank you,
Powell
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
