>>> * 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 ...>
<or>
<available ....>
<uptodate ...>
</or>
</condition>
>>> * 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.
Stefan
