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, Meg -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] 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 > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
