RE: [Clirr-devel] Maven plugin: filtering error messages

[Simon K. <si...@ec...>]

On Mon, 2004-07-05 at 19:03, Vincent Massol wrote:
> > On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:
> > 
> > > One thing that should now be fairly easy to support if you wish to is
> > > adding some stuff to the Ant task to allow users to selectively ignore
> > > certain messages. Because each message has a unique id, it should be
> > > simple to support tags in the ant file like:
> > >
> > >   <ignore-error class="com.acme.widget" message-id="7001"/>
> > >
> > > When a build "clirrs" (in your suggested terminology :-), but the user
> > > doesn't care about that particular problem, they could add a tag like
> > > this to suppress the error-counting for that problem. And it will work
> > > for any locale, because the message-ids don't change by locale.
> > >
> > > Just a thought....
> 
> I completely agree that we need a way to tell Clirr to ignore some checks.
> However, I'd prefer that this ignore list be specified with the name of the
> check (check id) instead of the message id. But I could live with both
> solutions.

Salut Vincent!

You mean give the user the option to ignore "all method-related errors"
for a class or set of classes?

That's much more coarse-grained than having the user say "ignore all
occurrences of error#7012", ie cases where a method has been added to an
interface.

I *believe* (without any evidence at all :-) that the latter is more
useful than the former. 

But *both* would be useful. I could certainly live with a 0.4 release
that only provides disabling of "all checks for method-related errors".
It would at least provide users with a way to continue using clirr when
it reports errors they wish to ignore - though possibly at the cost of
accidentally ignoring some errors they did *not* intend to ignore.

On an implementation note, however, it is far *simpler* to exclude
errors with certain message codes from the "core" point of view.
Implementing the "exclude all method-related errors" would probably best
be implemented by excluding all messages in the range 7000-7999. But
given that, why not expose the finer control to the user?

Regards,

Simon