ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject AW: ant xdocs! it ran!
Date Tue, 18 Feb 2003 09:58:52 GMT
As a future "tool vendor" I am very interested in this thread
(how should documentation of task in the future be done).
I am working on a code generator which produces an initial code
skellet. It works for the code and the build file, needs some more
work for test code and HTML manual ...

But I don´t use Ant via GUI or introspection :-)

Jan Matèrne

-----Ursprüngliche Nachricht-----
Von: Erik Hatcher []
Gesendet am: Dienstag, 18. Februar 2003 10:46
An: Ant Developers List
Betreff: Re: ant xdocs! it ran!

On Tuesday, February 18, 2003, at 04:29  AM, Christopher Lenz wrote:
> Hi all,
>> Back to the original point of do not repeat ourselves... if we try to 
>> invent some way of codifying such validation rules in @tags we'll end 
>> up with the same out of sync issue.  I'd rather us err on the side of 
>> just using the English language (or perhaps localize it all somehow) 
>> to define these loose things.  This duplicates the validation rules a 
>> little too, still, because they'll be in Java code and also in a text 
>> description.  These two will be in very close proximity though.
> With the disadvantage that the validation rules then can't be figured 
> out by tools, which would be nice.

One step at a time :)

It would be a major change attempt how Ant works.  I think we need to 
accept how things work currently, and use those as our base assumptions 
for this documentation overhaul.  The tool integration is, at this 
point, more of a "bonus" than an expressed need.  I haven't heard the 
Eclipse or NetBeans folks speak up here, although I know that NetBeans 
has submitted several documentation patches to have Ant's task 
documentation friendlier for their environment.

I would love to hear what tool vendors have to say about this work and 
where their thoughts are with Ant integration.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message