ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Question about property name
Date Fri, 21 Apr 2006 23:00:14 GMT
Hazzard, Powell wrote:
> Thanks Meg, for the introduction.
> Hello Steve,
> 	My name is Powell Hazzard and I am one of the original OpenVMS
> Java engineers.  I have also worked other Open Source products like
> Tomcat, Mozilla...  I'm currently working with Meg regarding
> understanding (and hopefully resolving) the Ant junit test failures on
> OpenVMS.  

Welcome. And thank you all for running ants unit tests on a platform 
that isnt rigorously checked (till now). It is not too late to get fixes 
in for Ant1.7.

> 	Thank you for your comments regarding new "magic" OpenVMS
> properties, believe me when I say that I completely understand your
> comments.  I also agree with your idea about a pluggable exit
> interpreter in the future. I feel I should explain in detail as to why I
> thought Ant needed an OpenVMS property and that I'm open to any
> "guidance" you would like to offer.
> 	I have observed that with most Open Source projects, zero is
> treated as success and non-zero as failure (or as a special status
> code).  

That's the historical unix way of things. Some apps check for -1 as the 
return code which burns them on SYSV systems that return 255 instead, so 
we already have a bit of platform-inconsistency from time to time.

> Whereas with most native OpenVMS scripts/executable the
> low-order 3 bits of the returned status value represent the severity of
> the status. Severity values range from 0 to 4, as shown in the following
> table: 
> Value  Severity 
>     0  Warning
>     1  Success
>     2  Error
>     3  Information
>     4  Severe (fatal) error  
> 	While I was initially pleased to find the recent Ant changes
> (not made by us here in OpenVMS engineering, BTW, which doesn't matter
> at all) that support these values; after attempting run Ant's and
> Jboss's junit tests on OpenVMS it became clear that we might have a
> strong need for return statuses that matched the "Open source"
> philosophy.  This means some way to support two environments.  One
> environment that will support applications that expect the Open Source
> success as zero, and one environment that will support VMS status codes.

I guess if JBoss shows the problem, then yes, some kind of external 
control makes sense. But having one big switch that suddenly flips the 
response processing over is scary, very scary, because Execute() is used 
everywhere, even in things like Java.
> As for my change to isFailure, we're happy to consider a different
> implementation.  You're right about Exec being used in lots of places.
> Actually, Exec isn't the only place that exit codes are checked, and
> therefore, whatever type of solution we settle on will need to address
> other tasks that check return statuses as well.  I have found in other
> parts of the Ant source that there is code that checks the status return
> values without using isFailure.  I suppose one could consider these
> checks a bug?  

Probably. Some will be historical, as that isFailure test only went in 
for openVMS in the first place.

however, there is no way to stop it being used by other people; Execute 
is a broadly used piece of code.

>If what you're suggesting is to add a method to some
> utility package that would implement the status checking in one place
> that all these different classes could call, then I could see that.
> Here is a list of what I've found so far:
>         assertEquals(0, process.exitValue());


>         return exe.getExitValue() == 0;	

Yes. And as that is an Ant1.7 feature it can be changed without 
problems. I've just corrected it.

Of course, we do have a little problem here. Execute.isFailure() is 
static. Whether its configurable by a project property or by a 
per-instance option, that test is now bound to a project and perhaps an 
Execute instance. So a static variable is wrong. Really we need an 
Execute.isFailure() that looks at the exit value and does the right thing.

>             err = proc.exitValue();
>             if (err != 0) {
>                 if (failOnError) {

yes, but look at the constructor

     public Exec() {
         System.err.println("As of Ant 1.2 released in October 2000, "
             + "the Exec class");
         System.err.println("is considered to be dead code by the Ant "
             + "developers and is unmaintained.");
         System.err.println("Don\'t use it!");

Maybe its time to delete that class

> 	In conclusion, I can see the need for the two types of behavior,
> Open Source and Native OpenVMS.  I fully believe that all Open Source
> code should work the same regardless of platform; I feel the default for
> Ant should be supporting the Open Source environment to promote 100%
> compatibility even if a user written task doesn't call isFailure.

> That's why I thought of using some kind of switch/property to control
> the way the return value is interpreted.

I see this, but dont want to resort to lying about return values unless 
it can be avoided.

The other area of trouble is Java, which can use exec, which always does 
the java interpretation of return codes, but often returns 0 for bad 
things (like exceptions caught and logged when failonerror=0)

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

View raw message