Holger Joest

Blog

I've set up a precompiled Maven Checkstyle Plugin with MCHECKSTYLE-91 fixed. Follow this link to download the plugin.

Alternatively, you may put the following plugin definition to your pom.xml :

<project>
    ...
    <pluginRepositories>
        <pluginRepository>
            <id>joest</id>
            <name>Maven Repository repo.joest.org</name>
            <url>http://repo.joest.org</url>
        </pluginRepository>
    </pluginRepositories>
    ...
    <reporting>
        <plugins>
            ...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>2.2-MCHECKSTYLE-91</version>
                <configuration>
                    ...
                </configuration>
            </plugin>
            ...
        </plugins>
    </reporting>
    ...
</project>

During Christmas time, I digged into the internals of Checkstyle and the Maven Checkstyle plugin. Automated code review is a must for any serious software development project and, to my mind, nearly all of the standard rules provided by Checkstyle should be made mandatory in a way that violations break the build. But there is a difference between main and test sources. For example, there is no point in writing Javadocs on unit tests, and thus it's annoying to have Checkstyle constantly complaining about it.

Unfortunately, version 2.2 of the Maven Checkstyle plugin doesn't allow for applying different rules to main and test sources. So I started to write a patch that adds a new parameter testConfigLocation to the Checkstyle report generator.

The patch should be applied against Subversion revision 728546 of
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin.

Here's my public key:

Public Key: 0xe3a9a5caeb2a4cd0
Created: 2008-11-20
Expiration: 2009-05-19

mQGiBEklXYYRBADTAu8z4T7wQfuvyNtYAiH+XQKy+1LtLhRqkSGmL+woWKUiFwFUTLlWeIju
LJeVW1lJJiD/TD/HoQIKElHpuQ8GSif3h5RxBwOC8BxWtbm1wEW6W20mi2IMH/Kesz33LO6V
PTbr8UP91uZJVoCON3txqSbRtewFB3t/fNZn4w3NRwCgjihZEckXPCqjSSBe20mPo2nuxikD
/1Ek+mN0UFC+2kTU7ZyaagjjrXQG4bHx36yGtDbtekLRmxV2nIUGWZqnG7bbGEgVED1uuvG9
oC5kaHqLixXW7b+J1NQoQFmfH14gPSz4mxBjIZBZwMIgsRWpwl/KeyU0tZd0jiYEc+apyHDL
dSN4mmJgzvYDn95Wxj9JrN1gz+tJA/9iD5CwM1HbgrWM5ZCswywrPN+Ke8zCa5XPd9m4VvBb
T6Wih5fmeIYizm5URr5VpsrOQwHSv7BVK5I7GrDH+wekrkWB98t0+grlktL7KPWDlosqLArl
vqw2umOAhi0GmqZcRnLurEvRmg1JGBqd/su8PqngkilH9JQ4ZXiVl7aI+bQfSG9sZ2VyIEpv
ZXN0IDxob2xnZXJAam9lc3Qub3JnPohpBBMRAgApAhsDBQkA7U4ABgsJCAcDAgQVAggDBBYC
AwECHgECF4AFAkmdW7kCGQEACgkQ46mlyusqTNBJfQCeNao+5y8UWSWx3W/byPGIzNz4/8AA
n1nXSwgx8zp6hGWsucpJLmjminFWtCNIb2xnZXIgSm9lc3QgPGhvbGdlci5qb2VzdEBnbXgu
bmV0PohmBBMRAgAmBQJJJV2GAhsDBQkA7U4ABgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQ
46mlyusqTNAJ2QCgi+B2x1FcaQ+Li1K4DXKjWlL0o5wAn2KPefLyTD3IWuZjZYycx1AH5wa4
uQINBEklXYwQCADzpMsojNkYFg/bRSliMJ9wdA9oQVTAK2JIExqx5NB5d39GelSsq5BmFrJx
tB30IBOCsUJHgx4t9H3Fj4v8EMQJke/gokJO7ftN89NTKL5GZdVEZCrJs1NZ6St78kbkQXfp
77buLTN+tCEY7069uzcrW55GWyXYTpON2uQGbpUKmleA4S12SEJPRcNhkPsgmW4cRlr86MoQ
feM+VIvcEkVKgYuB+2gmNUrydRoH9nIuOICNJSCpGcOdigAhxtEVuJq3T6zE7w342EO8fW0s
xggyTQAytb75ykiB1Kr6Z3ItS9zBzCh43KvkgP6pPSK8QlMlKOkmjzcqJmarQj0i2oQDAAMG
CADu8e97ItZCF4rNWwEyy5+o9HEGz7fZy2y3wGHsnzwsaHzXpszsX9GAEA0tZZ8590CxzFu0
1mf/yOvBeXCkRP+By7Ua9BqYJL4LAqATSMhUYpsdxdpqt0YuTpAe8tqaPivJFzG9vh4UkDp3
830W6/UrXP+i9D+FHcRoJcqyPGn+TdILtWF/sLQHLYver1L/sqaEqnQg61a2ff7R0tcuWkO4
3BiFW2uMMa4Lrnp00TJqddOiRFudq/eSmWpT9mwplAmNNPmnB2eF+wejmZRLwcvSuVvHe09q
d1JvqUM51BAX9S6OzaMHxbitK75V9JhfBVxaeMlWlo99JnMWHr9JZHxGiE8EGBECAA8FAkkl
XYwCGwwFCQDtTgAACgkQ46mlyusqTNAbIgCeJaY95AbmRxJbleTmT0pIHYi/COAAnRLbIIbh
ldOXOnswsItq3CGLpzcQ
=PiLG

Javadoc is a tool for generating API documentation, but unit tests don't have APIs. It's fine to write comments on unit tests. But Javadoc doesn't make sense for unit tests.

Why violations of Checkstyle rules should break the build.