commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <>
Subject Re: [general] checkstyle report
Date Sun, 20 Oct 2002 15:28:03 GMT
> Just a note from some experiment I've done on projects at work and on
> Cactus:
> - I've turned on the build failure on checkstyle errors. The initial
> period was a bit of a pain but then afterwards, everybody loved it as :
>   - it is not possible to introduce any more coding convention error as
> the build will report it (be it local build or Gump)
>   - it forces each developer to correct one's own code and not force
> other developers to correct checkstyle errors introduced by someone 
> else
>   - there is almost no overhead as commits are usually small, so
> correcting a few checkstyle errors is absolutely not a pain
>   - it kind of "forces" developers to run a local build before
> committing, which should always happen
Good idea.  It would be great if all *new* projects followed this
pattern ;)

> Now, in order to overcome the initial period where lots of checkstyle
> errors exist, I've found the following strategies to work quite well:
> - When using the checkstyle task, it is possible to specify the code 
> the
> classes that are checked. Thus, you would write 2 checkstyle checks: 
> one
> for code that is supposed to have no more checkstyle errors (and
> failonerror is true for this ant task) and one for code that is not yet
> free of checkstyle errors. As classes are cleared of checkstyle errors,
> they are moved from one set to the other. This allow to gradually bring
> number of errors to 0.

> - The other solution is by checkstyle checks. It is possible to tell
> checkstyle for example to only check for unused imports. So you could
> also have 2 checkstyle tasks, one checking for some type of errors and
> failing the build in case of error and another one checking for the 
> rest
> but not failing the build.
> - Of course, the 2 approaches can be combined with no problem.
> The only "issue" I would say is Maven. ATM, the checkstyle plugin for
> Maven does not support this strategy. However, I believe it would be
> quite possible and easy to implement it should it be something that we
> want to do.
I'll do some investigation into this when I get a chance.  I'll be 
at getting checkstyle to generate a report on the coding style, maybe
it does it already I don't know, so I'll take a look at the checkstyle
plugin as well to see what I'll have to do.

-John K
- - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message