[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ant-dev
Subject:    Re: [DISC] task/documentation writer's business
From:       Peter Donald <donaldp () apache ! org>
Date:       2001-03-29 12:36:34
[Download RAW message or body]

One thing you may have noticed has been my "theme" is to try and simplify
everything. At the moment there is a lot of "overiding" and while it can be
simple for people in the know it is a PITA for rank amateurs.

One example is available - every now and again we have added an extra test
to it. Before long it could easy grow to ludicrous sizes (if you don't
consider it ludicrous at the moment). So in many ways I want to step away
from loose typing and into a strong typing for ant. I am not going to get
into a language war but in most cases people with low technical skills are
benefitted by strong typing.  

As one of the main audiences I have pushed ant to is web-dev guys - people
who have little (or zero) knowledge of "programming" and think HTML is a
prgramming language ;) Hence I really want it to be easy for them. I have
already resigned myself to writing xslt sheets to convert some of the
primitive forms into complex forms (ie copyfile->copy) but I would prefer
if the core was as simple as possible while still maintaing power.

Given that as background...

At 01:54  29/3/01 +0200, Stefan Bodewig wrote:
>The stuff that didn't get enough - or negative - votes in the first
>pass.
>
>>> * 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).

I would completely +1 this on this if there was some notion of stronger
typing rather than overloading elements to do N differnent things.

>>> * 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

Don't consider that as a veto - consider it as a "I won't support it but
feel to create a .tsk to do it" ;)

>
>Stefan Bodewig wrote:
>
>> +0, well, we might need to revisit this later - maybe we don't need
>> it at all as the core (or a preprocessor or whatever) would provide
>> the functionality.
>
>------------------
>
>>> * Include some more sophisticated loggers with the Ant distribution
>>> * - especially for sending emails. Make the existing one more
>>> * flexible (stylesheet used by XmlLogger).
>
>Conor MacNeill wrote:
>
>> +1 - This may affect the core if this is going to be specified in
>> the build file and require the email message to be defined. More
>> sophisticated loggers require more sophisticated configuration than
>> command line options.  So, does that mean I should have said -1?

I think we could expose the functionality to listen for tasks either in
buildfile or in some sort of config file

>>> * 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
>> 
>> <file-property ... />
>> <data-property ... />
>> <load-properties ... />

I stand by this ;) Of course this will directly be influenced by the
implementation of datatypes.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

[prev in list] [next in list] [prev in thread] [next in thread]