On Thu, 9 Jan 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > 1) ZipScanner class > > it is currently implemented in such a way that the > getIncludedFiles() function answers with an array containing as only > element the name of the zip file itself. > > I believe we should change the implementation of the class so that > ZipScanner.getIncludedFiles() gives the list of entries in the > archive which match the include and exclude patterns. > > Does anyone see a danger of breaking something here ?
Yes (and no). The only classes using ZipScanner are Zip and ZipFileSet. As Zip would get adjusted, we won't have a problem here, but ... <zip ...> <zipfileset src="foo.zip" id="foo"/> </zip> <copy ...> <fileset refid="foo"/> </copy> would break. Copy would try to copy files with the names of the ZipEntries. Then again, a construct like this would be silly, as it wouldn't really work right now either. > maybe we could create such a Resource class under > org.apache.tools.ant.types it needs only two instance variables : > String FileName and long ModificationTime or something like that Yep. > Then the DirectoryScanner could store the results of > scanning internally as vectors of Resource OK. > Classes interested in knowing the modification date/time of a file > should ask the scanner, not the file directly any more. Why? They might be better of accessing the Resources directly. > one would add two new functions in DirectoryScanner > long getModificationTime(String path) See above. > and > Resource [ ] list(String path) Under which circumstances would you expect more than one resource for a given path? Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>