[
https://issues.apache.org/jira/browse/IO-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601190#action_12601190
]
niallp edited comment on IO-172 at 5/30/08 9:25 AM:
-------------------------------------------------------------
> how would one search for files that match "*/.xml" but that don't match
> "bad/**"?
Currently, the way would be to create a DirectoryWalker implementation:
{code:java}
public class FileFinder extends DirectoryWalker {
public FileFinder(IOFileFilter dirFilter, IOFileFilter fileFilter, int
depthLimit) {
super(dirFilter, fileFilter, depthLimit);
}
/** find files. */
public List find(File startDirectory) throws IOException {
List results = new ArrayList();
walk(startDirectory, results);
return results;
}
/** Handles a directory end by adding the File to the result set. */
protected void handleDirectoryEnd(File directory, int depth, Collection
results) {
results.add(directory);
}
/** Handles a file by adding the File to the result set. */
protected void handleFile(File file, int depth, Collection results) {
results.add(file);
}
}
{code}
Then you use the file filter implementations to achieve what you want:
{code:java}
IOFileFilter dirFilter =
FileFilterUtils.notFileFilter(FileFilterUtils.nameFileFilter("bad"));
IOFileFilter fileFilter = FileFilterUtils.suffixFileFilter(".xml");
FileFinder finder = new FileFinder(dirFilter, fileFilter, -1);
List files = finder.find(new File("."));
{code}
was (Author: niallp):
> how would one search for files that match "*/.xml" but that don't match
"bad/**"?
Currently, the way would be to create a DirectoryWalker implementation:
{code:java}
public class FileFinder extends DirectoryWalker {
public FileFinder(IOFileFilter dirFilter, IOFileFilter fileFilter, int
depthLimit) {
super(dirFilter, fileFilter, depthLimit);
}
public List find(File startDirectory) {
List results = new ArrayList();
try {
walk(startDirectory, results);
} catch(IOException ex) {
Assert.fail(ex.toString());
}
return results;
}
/** Handles a directory end by adding the File to the result set. */
protected void handleDirectoryEnd(File directory, int depth, Collection
results) {
results.add(directory);
}
/** Handles a file by adding the File to the result set. */
protected void handleFile(File file, int depth, Collection results) {
results.add(file);
}
}
{code}
Then you use the file filter implementations to achieve what you want:
{code:java}
IOFileFilter dirFilter =
FileFilterUtils.notFileFilter(FileFilterUtils.nameFileFilter("bad"));
IOFileFilter fileFilter = FileFilterUtils.suffixFileFilter(".xml");
FileFinder finder = new FileFinder(dirFilter, fileFilter, -1);
List files = finder.find(new File("."));
{code}
> Support directory scanning based on Ant-like include/exclude patterns
> ---------------------------------------------------------------------
>
> Key: IO-172
> URL: https://issues.apache.org/jira/browse/IO-172
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
> Affects Versions: 1.4
> Reporter: Benjamin Bentmann
>
> While IO offers a rich set of {{IOFileFilters}} for finding files in
> directories, I feel it's missing a concept similar to Ant's file sets. For
> example, how would one search for files that match "**/*.xml" but that don't
> match "bad/**"? The sketched example would require to exclude the directory
> "bad" but only if it is the first component of the path, something like
> "foo/bad/bar.xml" still needs to be included.
> Given the increased flexibility of [Ant-like
> patterns|http://ant.apache.org/manual/dirtasks.html#patterns], it would be
> cool to have something similar to Ant's
> [{{DirectoryScanner}}|http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/DirectoryScanner.java?view=markup]
> available in Commons IO.
> Personally, I wouldn't need a full copy of the mentioned class, I believe
> some method like
> {code:java}
> Collection<String> scanDirectory(File dir, Collection<String> includes,
> Collection<String> excludes)
> {code}
> in {{FileUtils}} would just suffice. Some default excludes like SCM metadata
> files could be provided as a public static final and unmodifiable string
> collection. The return value should include path names relative to the base
> directory instead of absolute paths (it's easy for the caller to resolve the
> files against the base directory but it's error-prone to relativize absolute
> paths).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
