ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Proposed refactoring of scanDir() functionality
Date Fri, 03 Nov 2000 11:02:13 GMT
At 11:07  3/11/00 +0100, you wrote:
>You can find a lot of duplicated code here, so I'd like to separate
>this logic into another class with just a 
>public static String[] scanDir(File srcDir, File destDir, String[] files,
>                               FileNameMapper mapper)


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


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

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

I can't think of any good reason why not, it will be a little slower but
not anyworse than what we currently got.

>(2) same for mapFileName

seems okay ... thou I have an icky feeling not sure why thou ;)

>(3) should we move destdir as an attribute to the FileNameMapper
>instead of passing it to scanDir.



Well as you are talking about refactoring I guess I should mention the
following. Remember ages ago when I was clamouring how I didn't really like
how  the internals of ant were engineered. Namely there was a lot of
redundent coding to check for variables, extensive use of static method
calls, there can only be one instance of project at a time, the wastage of
memory during parsing etc.

I had a version of ant back then that fixed some of these things and just
yesterday I started looking at it again (It is really ugly thou ;]). I
decided to refactor the whole thing to solve all these problems etc.
Currently I am playing with it running via some of the interfaces in Avalon
( and it *seems* to be a little better (not sure
yet - need more time to play ;]). It now allows arbitrary embedding such in
any environment with less gotchas. Anyways I am going to play with it a bit
more and see if anything useful comes out of it.

My main aim is to seperate all different parts - ie into a
TaskExecutionEngine, TaskEnvironment (that has variables and environment
data: scoped or un-scoped), TargetManager, TaskInputSource etc. So this
kind of architecture will allow experimentation using a lot more different
interacting parts so if people want to replace the front end with something
that includes all sorts of ugly scripting constructs they can ;) It should
also reduce start up time.

Anyways my dev computer is not attached to network but when it gets
attached I may place it in CVS/on a web page to see what you think and if
it is a useful direction. This should hopefully make it a little easier to
maintain aswell ;)



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message