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

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

On Mon, 2004-07-05 at 19:37, Vincent Massol wrote:
> > -----Original Message-----
> > From: cli...@li... [mailto:clirr-devel-
> > ad...@li...] On Behalf Of Simon Kitching
> > Sent: lundi 5 juillet 2004 09:19
> > To: cli...@li...
> > Subject: RE: [Clirr-devel] Maven plugin: filtering error messages
> > 
> > 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?
> 
> No I meant more fine-grained than this. For example "Method signature
> change", "Method return type changed", "Class changed to interface", etc
> 
> Look at the way Checkstyle works. Each check has a name. For example:
> NoWhitespaceBefore. The good thing is that the classes implementing these
> checks have this same name. And excluding a check actually boils down to
> excluding a class.

But clirr's check classes aren't as fine-grained as that. Each check
class can detect up to a dozen different sorts of problems. And I doubt
a serious refactoring of the check classes into one-message-per-class is
going to happen, or is even possible.

Filtering on "message ids" would give exactly the level of control that
filtering on CheckStyle check classes gives. The only difference is that
the identifier to filter on is a number instead of a classname.

Regards,

Simon