ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: <exec> on openvms
Date Thu, 10 Jul 2003 10:57:50 GMT
On Thu, 10 Jul 2003, Knut Wannheden <> wrote:

> At our company we're developing Ada95 code for various platforms,
> including OpenVMS.

You are the first person reporting anything about Ant on OpenVMS

I used to work with OpenVMS about seven to five years ago, but I've
never done any Java development there.  I've often wondered how Ant's
file handling code was going to work there, given the file name syntax
that doesn't really fit the notion of a "file separator char".

I take your problems with <exec> as an indication that the rest of Ant
seems to work, yes?

>  - To use Runtime.exec() the command to be executed usually has to
>  be written into a temporary DCL script first.  Then this script is
>  executed using Runtime.exec().

Why?  Is this something specific to the VM implementation or a
limitation imposed by Ant?  Can we solve this by an OpenVMS specific
command launcher in Execute?

>  - The Java 1.4 JVM provided by Compaq/HP has some problems with
>  Runtime.exec().  Specifically it doesn't support the variant of
>  Runtime.exec() with a specified working directory
>  (Runtime#exec(String[], String[], File)).

Should be easy to fix.  We already special case OS/2 here as IBM's 1.3
VM for OS/2 ships with a bogus implementation.  What does the
system property look like?

>  - The Ant <exec> task throws a BuildException if the exit code is
>  unequal zero.  On VMS an odd exit code signifies success and even
>  exit codes are errors.  (The exit code zero actually signifies a
>  warning.)

I knew that, but I thought that System/Runtime/Process implementations
would hide it.

This makes Java's System.exit quite a bit inferior to C's exit using
the EXIT_SUCCESS and EXIT_FAILURE constants from stdlib.h, DEC's C
compiler used to define them correctly.

> I implemented my own <exec> task by subclassing ExecTask to get
> around these incompatibilities.

I'd prefer an approach that localized the changes in Execute instead,
if possible.


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

View raw message