Hazzard, Powell wrote:
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.
Welcome. And thank you all for running ants unit tests on a platform
that isnt rigorously checked (till now). It is not too late to get fixes
in for Ant1.7.
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).
That's the historical unix way of things. Some apps check for -1 as the
return code which burns them on SYSV systems that return 255 instead, so
we already have a bit of platform-inconsistency from time to time.
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.
I guess if JBoss shows the problem, then yes, some kind of external
control makes sense. But having one big switch that suddenly flips the
response processing over is scary, very scary, because Execute() is used
everywhere, even in things like Java.
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?
Probably. Some will be historical, as that isFailure test only went in
for openVMS in the first place.
however, there is no way to stop it being used by other people; Execute
is a broadly used piece of code.
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());
Fixed.
ForkingSunRmic.java
return exe.getExitValue() == 0;
Yes. And as that is an Ant1.7 feature it can be changed without
problems. I've just corrected it.
Of course, we do have a little problem here. Execute.isFailure() is
static. Whether its configurable by a project property or by a
per-instance option, that test is now bound to a project and perhaps an
Execute instance. So a static variable is wrong. Really we need an
Execute.isFailure() that looks at the exit value and does the right thing.
Exec.java
err = proc.exitValue();
if (err != 0) {
if (failOnError) {
yes, but look at the constructor
public Exec() {
System.err.println("As of Ant 1.2 released in October 2000, "
+ "the Exec class");
System.err.println("is considered to be dead code by the Ant "
+ "developers and is unmaintained.");
System.err.println("Don\'t use it!");
}
Maybe its time to delete that class
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 see this, but dont want to resort to lying about return values unless
it can be avoided.
The other area of trouble is Java, which can use exec, which always does
the java interpretation of return codes, but often returns 0 for bad
things (like exceptions caught and logged when failonerror=0)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
