On 2011-03-21, Marvin Humphrey wrote:
> On Mon, Mar 14, 2011 at 05:26:17PM +0100, Stefan Bodewig wrote:
>> RAT creates a commons-io WildcardFileFilter from each exclude provided
>> which behaves like Unix glob matchers (* and ? work like expected),
>> except that they are applied to the children of a directory
>> immediately. This means you can only match on the filename but not on
>> its path.
> Looking at the code, I don't think this behavior was intended. Here's the
> ignored() method from Walker.java:
> protected final boolean ignored(final File file) {
> boolean result = false;
> final String name = file.getName();
> final File dir = file.getParentFile();
> if (filter != null) {
> result = !filter.accept(dir, name);
> }
> return result;
> }
> Since the filter is being supplied with both the dir and the filename,
> it sure looks to me like the author wanted the filter to take both
> into account.
Well, at least to be able to. It is quite possible that using
WildcardFileFilter still was a conscious choice, I simply don't know it.
It allows you to exclude *~ rather than **/*~ which would be the Ant
pattern if you take the directory into account.
If you want to implement a different command line option (the backwards
compatibility problem would still be valid even if the choice was wrong
years ago) you could likely implement it by implementing a different
filter.
> I believe the problem arose because of the commons-io WildcardFileFilter
> interface.
> WildcardFileFilter's accept(File, String) method is really weird. It
> takes a directory, but doesn't do anything with it:
This seems to be common for the filters in commons-io. RegexFilter does
the same.
> So, if RAT wants to work with WildcardFileFilter in such a way that it
> *does* pay attention to the dir, it has to invoke accept(File) from
> the java.io.FileFilter interface (which WildcardFileFilter implements
> in addition to java.io.FilenameFilter).
> However, Walker's public API is built around FilenameFilter. It
> wouldn't be easy to migrate to FileFilter.
True.
> I don't think RAT's CLI is fixable to match paths without breaking
> backwards compatibility.
I agree that trying to split the path for wild cards isn't too easy, it
may be simpler by using something more standard. A FilenameFilter that
uses a regular expression, re-creates the original file from dir and
name and the applies the regex to the combined name, for example.
Stefan
