You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@bost.de> on 2000/11/03 11:07:47 UTC
Proposed refactoring of scanDir() functionality
Hi,
most every task that uses filesets (whether explicit or implicit) has
a scanDir() method that takes all files from the fileset, compares
their timestamps to the one(s) of a target file (some target files)
and builds up a list of those files that need to be handled by the
task.
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)
For javac this would return fileName with .java converted to .class,
for copy it was a identity transformation, for jar it would always
return the archive's name, for rmic it would return _Stub.class and
_Skel.class with the matching prefix and so on.
scanDir would then return an array of all files that are newer than
any of the files the mapper returned for them.
Apart from this I see another use for FileNameMapper. Say the one we
need for javac is generalized to a GlobMapper (mapping *.java to
*.class in the javac case), then we could add a nested mapper element
to move and have
<move fromdir todir>
<mapper type="glob" argument="*.oldext/*.newext" />
</move>
which would be the same as the optional RenameExtension task. I could
even think of an optional RegexpMapper based on jakarta-regexp and so
on.
Tasks that could be made more powerful that way include copy, uptodate
and maybe even style (which holds a hard coded GlobMapper but I see no
reason why it should be restricted to that) and probably others.
I'd also base new tasks transform and jtransform on this.
Things I'm not really sure about yet:
(1) should scanDir return a File[] instead of a String[]?
(2) same for mapFileName
(3) should we move destdir as an attribute to the FileNameMapper
instead of passing it to scanDir.
Comments?
Stefan
Re: Proposed refactoring of scanDir() functionality
Posted by Peter Donald <do...@apache.org>.
At 04:33 13/11/00 -0800, you wrote:
>On 11/3/00 4:39 AM, "Peter Donald" <do...@apache.org> wrote:
>
>>> You are far more familiar with Avalon than I am, would your vision
>>> make Ant depend on Avalon?
>>
>> well it could (and IMHO should) but we could make it independent by
>> reimplementing stuff they already have.
>
>-1. Ant should depend on itself to the maximum extent possible. Reusable
>frameworks are good -- but Ant needs to be as self reliant and small and
>easy to build as possible.
Well it can just incorporate into same jar via a jlink task. I don't see
any need to reinvent the wheel thou. There has already been requests to
create things that map to things in Avalon 1-to1. (ie command line parsing,
logging etc). I really don't see it as a good thing to reinvent the wheel
except for performance or license reasons - neither of which apply here. Do
you still think it would be better to reinvent the wheel ?
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Proposed refactoring of scanDir() functionality
Posted by James Duncan Davidson <du...@x180.com>.
On 11/3/00 4:39 AM, "Peter Donald" <do...@apache.org> wrote:
>> You are far more familiar with Avalon than I am, would your vision
>> make Ant depend on Avalon?
>
> well it could (and IMHO should) but we could make it independent by
> reimplementing stuff they already have.
-1. Ant should depend on itself to the maximum extent possible. Reusable
frameworks are good -- but Ant needs to be as self reliant and small and
easy to build as possible.
--
James Duncan Davidson duncan@x180.com
!try; do()
Re: Proposed refactoring of scanDir() functionality
Posted by Peter Donald <do...@apache.org>.
At 01:12 3/11/00 +0100, you wrote:
> 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?
well it could (and IMHO should) but we could make it independent by
reimplementing stuff they already have.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Proposed refactoring of scanDir() functionality
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "PD" == Peter Donald <do...@apache.org> 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.
Fine.
Stefan
Re: Proposed refactoring of scanDir() functionality
Posted by Peter Donald <do...@apache.org>.
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)
>
+1
>where FileNameMapper is an interface with the single method
>
>public String[] mapFileName(String fileName)
+1
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.
-1
>Comments?
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
(java.apache.org/framework) 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 ;)
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*