ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Proposed refactoring of scanDir() functionality
Date Fri, 03 Nov 2000 12:12:36 GMT
>>>>> "PD" == Peter Donald <> writes:

 PD> At 11:07 3/11/00 +0100, you wrote:

 >> where FileNameMapper is an interface with the single method
 >> public String[] mapFileName(String fileName)

 PD> +1

 PD> Question does this mean one input file can create multiple output
 PD> files ?  What about vice versa ?

It does mean multiple "output" files for one input, like in the rmic
example. Vice versa would be the zip/tar way, simply return the same
File instance for all invocations.

 >> (1) should scanDir return a File[] instead of a String[]?

 PD> I can't think of any good reason why not,

I've not yet tried to look at all the tasks using the scanDir
mechanism. Some tasks like javac and rmic don't need them to be Files,
they'd even need to strip of the source directory from the filename
returned to pass it to the compilers.

 PD> Remember ages ago when I was clamouring how I didn't really like
 PD> how the internals of ant were engineered.

TaskContext, Tasklets and so on? Yes I remember it ;-)

 PD> Currently I am playing with it running via some of the interfaces
 PD> in Avalon

You are far more familiar with Avalon than I am, would your vision
make Ant depend on Avalon?

 PD> when it gets attached I may place it in CVS/on a web page to see
 PD> what you think and if it is a useful direction.



View raw message