ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: javadoc/NT : Task not working
Date Mon, 31 Jan 2000 17:14:50 GMT


Wolfgang Werner wrote:
>
> Hello,
>
> I'm new to this list but using ant for a longer period of time. I found
the
> following (latest ant from CVS):
>
> javadoc - task is not working on NT. This is true because the NT
commandshell
> can (without extensions) only handle 9 parameters (see runant.bat).
>
> So the most needed parameters (packages/sourcefiles) are going to
/dev/nul...
>
> One way to overcome this limitation would be to generate a special
runtask
> Batch (at invokation time) rather than relying to runant.bat.

Good idea.  I also see an suggestion that repeated shifts be used to
construct a complete parameter list.  I'll experiment a bit and commit a
fix.

> One of the key features of ant should be '100% pure java', to name it:
The
> ability
> to work on every java supporting OS...

Ant, at times, is going to be messy.  I've been playing around with a jnic
(compile c/c++ code intended to be bound into a shared library / dll).  The
names of the compilers, and options, will vary dramatically from system to
system.

I think a more achievable goal will be that users of Ant are essentially
isolated from system unique considerations, and can code their build
process in 100% pure XML.

 - - - - - -

Stefano Mazzocci wrote:
>
> This is Sam's fault, I think.

Yup.

> Question: what's the point of going thru runant.bat anyway? before, I
> called javadoc directly from runtime.exec() and had no problems.

I intially did it so that std error could be redirected to standard out
(2>&1).  This caused problems on NT for Pier and myself, so I borrowed code
from Jasper/Jikes.  I see that that you've added a comment that this causes
a slowdown for you.  BTW - I don't routinely get to read these logs as
Brian has the cvs putback messages bouncing all over creation, and IBM
rejects it as likely spam candidate (no - I've not heard that officially,
but that's my favorite theory to date).

> This is why I patched Exec() to be able to "bypass" that shell wrapping.
>
> Sorry, but I miss that point.

I want all execs to go through the same logic.  That way, as we debug the
system unique problems for running one command, all commands will improve
accordingly.

- Sam Ruby



Mime
View raw message