Watson, Meg wrote:
Hi,
We're (a couple of us here at HP) are in the process of making some
changes to better support Ant on HP's OpenVMS operating system. See
http://issues.apache.org/bugzilla/show_bug.cgi?id=39359
One of the changes we are making has to do with determining success or
failure based on return value. On OpenVMS, a return value of 1 (or an
odd value) signifies success, and even numbered return values signify
failure. Some of our customers rely on this, while others would like us
to act like all the other "Unix-like" platforms. We'd like to make a
property available that our customers could set to control the behavior.
Are there any guidelines for making up property names?
We think it should be called something like os.supportVMSExit, which
when set to true would cause the VMS style return values to be used. By
default, however, the standard Unix-type return values would be used.
At any rate, we have no interest in the actual name/spelling of the
property, so we'd like the Ant dev team's advice.
There is a formal policy that
1. new "magic" properties are not something blindly adopted
2. new "magic" properties begin with ant. This is to minimise the risk
that someone else was using the property at the time and now their build
suddenly has wierd side effects from a new ant version adding a new
global setting.
(1) doesnt mean new ones dont go in; one went in last week to allow an
override of the java version for javac, but it was argued about for a
while first, and went in to let people build java1.4 things on java1.5,
so it was quite obvious to a lot of people and Apache gump.
Just for completeness, here's what we propose...a simple change in
Execute.java to isFailure for this...something like
/** Controls whether we honor VMS status or standard Unix exit
status **/
private static boolean supportVMSExit =
Boolean.getBoolean("os.supportVMSExit");
:
Exec gets used in lots and lots of places, as its the primary way that
Ant shells out to the OS. so if you flip a property to change how return
values get interpreted, everything that gets executed could break. And,
because properties are immutable, you cannot change behaviour on a case
by case basis.
Now, the sole rationale for having a property to drive this behaviour is
that it lets people outside of a build script to change behaviour. That
is, people other than the original authors, because they can just set an
attribute on the task.
I think it would be more flexible to have the notion of a pluggable exit
interpreter type; something that can process error codes on different
platforms and do the right thing. That way anyone can add custom logic
to interpret return codes for specific apps or platforms
OpenVMS-specific fault handling would just be a choice of
resultInterpeter="openvms" in the <exec> call.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
