commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Commented: (IO-172) Support directory scanning based on Ant-like include/exclude patterns
Date Fri, 30 May 2008 19:48:45 GMT


Niall Pemberton commented on IO-172:

Right, or we would have pointed you to somemethod to use and just closed this as INVALID.

The real point though is that it seems to me that we already have some of the building blocks
here in IO for such a thing and better IMO to start with that than copying in an Ant class.
DirectoryWalker recursively scans directories, applying file filters - so I think if there
was a file filter implementation that could do the pattern matching on paths and file names
then it would be straight forward to provide the one line scanDirectory() method you're looking

> Support directory scanning based on Ant-like include/exclude patterns
> ---------------------------------------------------------------------
>                 Key: IO-172
>                 URL:
>             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|],
it would be cool to have something similar to Ant's [{{DirectoryScanner}}|]
available in Commons IO.
> Personally, I wouldn't need a full copy of the mentioned class, I believe some method
> {code:java}
> Collection<String> scanDirectory(File dir, Collection<String> includes, Collection<String>
> {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.

View raw message