ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Watson, Meg" <>
Subject RE: Question about property name
Date Fri, 21 Apr 2006 15:52:59 GMT
Thanks for responding Steve.  I knew this was an area where we needed
"guidance."  I agree that your idea about a pluggable exit interpreter
type would be much more flexible...and safer.  If I understand what
you're suggesting, it seems like a good solution for the future, but
maybe not this late in the game for 1.7?  We (here at OpenVMS) need to
make sure that Ant 1.7 works on OpenVMS with other open source projects
that bundle it.

I'll let the other engineer I'm working with on this - Powell Hazzard,
he's actually coding the changes, and he works part-time on the OpenVMS
Java team - chime in with his thoughts.

Thanks Again,

-----Original Message-----
From: Steve Loughran [] 
Sent: Friday, April 21, 2006 10:28 AM
To: Ant Developers List
Subject: Re: Question about property name

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
> 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
> 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
> 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 
> 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.


To unsubscribe, e-mail: For additional
commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message