ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Proposed refactoring of scanDir() functionality
Date Fri, 03 Nov 2000 11:49:17 GMT
I would prefer everything to be File till the very last moment, certainly to
mapfilename. While doing the horrible file mapping required for the weblogic
jspc task (u add a few directories in front, and add an underscore before
each existing directory ...aargh) i foung myself converting from string to
files and back a bit too much.  

> -----Original Message-----
> From:	Stefan Bodewig []
> Sent:	Friday, November 03, 2000 3:38 PM
> To:
> Subject:	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

View raw message