Stefan,
Thank you for your articulate reply.
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.
Would it be acceptable to provide a patch for RAT which changes this behavior
to work on paths?
A couple different approaches are possible.
* Modify the interface for -e/--exclude
* Introduce a new command line flag.
> > For obvious reasons, it's not acceptable to exclude on filename or file
> > extension alone.
>
> But this is the only exclusion mechanism that is currently implemented
> inside the CLI, sorry.
Perhaps I just don't undertand the rationale, but to me, that seems like an
odd design. Apparently the Ant and Maven interfaces allow path-based
exclusions, so is the behavior of the CLI a bug?
> My guess is that most users of RAT don't use the CLI but either the
> Maven plugin or the Ant task which both provide superior methods to
> filter the files to be checked.
That sounds likely. However, Lucy is a C project with dynamic language
bindings, and does not currently incorporate Ant or Maven; few of us in the
Lucy community have expertise with either. Between that and the contention
that build system discussions tend to provoke, I don't think it's in the
project's interest to introduce Ant into our ecosystem just for this.
Instead, I'd be inclined to either attempt a nasty hack that wraps RAT and
tries to deal with false matches somehow, or accept that RAT is imperfect
under the best of circumstances and is simply more imperfect when used from
the command line.
Marvin Humphrey
