Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4448EC06.3030707@apache.org>
Date: Fri, 21 Apr 2006 15:28:22 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: Question about property name
References: 
 <88BD5A70CA8BFA4CA15D0ED053E49D690D2EE0BF@tayexc14.americas.cpqcorp.net>
In-Reply-To: 
 <88BD5A70CA8BFA4CA15D0ED053E49D690D2EE0BF@tayexc14.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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