ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [VOTE] task/documentation writer's business
Date Thu, 12 Apr 2001 08:39:27 GMT
>>> * Unify <available> and <uptodate> into a more general <condition>
>>>   task, support AND/OR of several tests here.
> Peter Donald wrote:
>> Depends on how it is done. If it is done via overloading then -1 if
>> it is done by creating new tasks for each condition then +1. (Heres
>> a perfect example where nested tasks work in Ants core).

+1 on doing this via separate elements, something like

<condition ...>
    <available ....>
    <uptodate ...>

>>> * Add an <ant> task that will find build files according to a
>>>   fileset and invokes a common target in them.
>>> * Add a JavaApply task that executes a given class with files from
>>>   a fileset as arguments - similar to <apply>.
> Peter Donald wrote:
>> -0
>> should be part of preprocessing

I don't see this happen.  

+1 on solving the original requests in core, whether this involves new
tasks or is supported by some API change depends on the design we end
up with.

>>> * Include some more sophisticated loggers with the Ant
>>>   distribution - especially for sending emails. Make the existing
>>>   one more flexible (stylesheet used by XmlLogger).

covered in another thread, +1 here as well.

>>> * make the default logger's output clear, informative, and terse.
> Conor MacNeill wrote:
>> -1  - I think it is OK as it is.

I've come to agree with Conor, -1 on the original item.

>>> * add an attribute to <property> to read in an entire file as the
>>>   value of a property.
> Peter Donald wrote:
>> -1. One thing I would like to see is property/available and other
>> similar tasks simplified by not overiding the tasks. Instead new
>> tasks like

+1 on making it a separate task.

>>> * make PATH handling consistent. Every task that has a PATH
>>>  attribute must also accept references to PATHs.
> Stefan Bodewig wrote:
>> -1, should be moved to "guidelines for task writers" IMHO - unless
>> we could simply enforce this from the core, in which case it
>> doesn't belong here either

This vote still stands.


View raw message