ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: 2.0 suggestions / questions
Date Wed, 21 Mar 2001 02:02:04 GMT
At 08:49  20/3/01 -0500, Eric Siegerman wrote:
>On Wed, Mar 21, 2001 at 12:02:38PM +1100, Peter Donald wrote:
>> At 07:03  20/3/01 -0500, Eric Siegerman wrote:
>> >1.  Can I do set arithmetic on FileSet's?
>> No need to in most cases.
>>     [suggested alternative deleted]
>> Not all tasks support [the alternative] but most that I have needed do.
>That's precisely the point of fileset arithmetic -- to factor
>this out in the ant code so that task classes don't need to
>*think* about it.

Yes we do intend to provide base utilities that are accessible to all
classes. In most cases the task writer don't have to think (or will not in
the future).

>Consider this a gripe about the lack of orthogonality in task
>implementations -- and a suggested (partial?) fix.  (Dunno
>whether it's a complete fix because I'm too new at ant to know
>how unorthogonal the tasks are in the first place.  But at worst,
>this would be a complete fix for one class of irregularities...)

This sort of talk is similar to what has just been discussed recently on
ant-dev. Being able to have aspects handled outside the task and then
"applied to task". Some possible implementations have been a lisp-like (map
function fileitems) or inheritance from base class etc.

>> Multiple
>> filesets combined with exclude/include (or patternsets) will work the magic
>> you need. 
>That's the other point :-) -- to let me factor such similarities
>out in my buildfile, so my task calls don't need to think about

Not sure what you mean. The filesets already handled nested patterns and
petternsets etc. The task writers don't have to handle it. The places where
tasks do handle it is for backwards compatability.

>> >3.  Can a mapper be used in the construction of a FileSet?  I'd
>> >    like to be able to say something like:
>> >	<fileset id="sources" .../>
>> >	<fileset id="classes" refid="sources">
>> >	    <mapper type="glob" from="*.java" to="*.class"/>
>> >	</fileset>
>> there has been a proposal for this. It may or may not get through - not
>> sure at this moment.
>Want to add mapper support to all existing tasks in one go -- and
>to all future tasks where they make sense with *zero* further
>effort?  This'll do it: don't bother adding mapper support to
>tasks; instead factor it out so that tasks don't need to worry
>about mappers.

agreed. But as I said - we will have to wait till the vote to see if it
gets through ;) So far no one besides you and me have been positive about
such a feature. (And I am not sure I am completely positive about it). The
problem comes because it adds complexity to the build file - where one of
our main aims is simplicity ;)


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

View raw message