Question about property name

["Watson, Meg" <me...@hp.com>]

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.

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");
:
:
:
     * Checks whether <code>exitValue</code> signals a failure on the
current
     * system (OS specific).
     *
     * <p><b>Note</b> that this method relies on the conventions of
     * the OS, it will return false results if the application you are
     * running doesn't follow these conventions.  
     * One notable exception is the Java VM provided by HP for 
     * OpenVMS - it will return 0 if successful (like on any other
platform), 
     * but this signals a failure on OpenVMS.  On OpenVMS use the
boolean 
     * property Os.supportVMSExit to have VMS exit semantics honored.
     *
     * @param exitValue the exit value (return code) to be checked.
     * @return <code>true</code> if <code>exitValue</code> signals a
failure.
     */
    public static boolean isFailure(int exitValue) {
        //on openvms even exit value signals failure;
        // for other platforms nonzero exit value signals failure
        return (Os.isFamily("openvms") && supportVMSExit)
            ? (exitValue % 2 == 0) : (exitValue != 0); 
    }


Thanks for your advice!

Meg Watson
HP OpenVMS Systems Software Group

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Question about property name

[Steve Loughran <st...@apache.org>]

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org