Sunday, October 28, 2007

Checkstyle report with Maven2

Sorry if I will not be precise enough but I spent some time until I managed to configure custom checkstyle to be included within report generated by maven2. I want to share this knowledge so maybe somebody will need not spend so much time on this because I followed description on checkstyle maven2 plugin but that didn't work.

I have found solutions from the following mailing list archive. Follows short description.

Problem is following. I have maven java project and custom checkstyle configuration. I want to include checkstyle report into maven2 generated report. Solution is:

Create new maven project and into resources folder include your custom checkstyle configuration file e.g. my_checkstyle.xml.
Deploy this project to local or your intranet maven repository.
For this example groupId is com.my.checkstyle and artifactId is checkstyle and version is 1.0-SNAPSHOT

Then within pom of project for which you want to have custom checkstyle validation add following lines:

<build>
<extensions>
<extension>
<groupid>com.my.checkstyle</groupid>
<artifactid>checkstyle</artifactid>
<version>1.0-SNAPSHOT</version>
</extension>
</extensions>
</build>

<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configlocation>my_checkstyle.xml</configlocation>
</configuration>
</plugin>
</plugins>
</reporting>

Run mvn site for your project and your customized checkstyle report will be included within your project.

Note: For some reasons, not all customizations work. Plugin is reporting errors when module element contains subelements like suppressLoadErrors. Currently I don't have enough time to play with this problem. I think solution is with using suppress warnings. If I return to this problem and find solution I will post it here.

Link to maven2 checkstyle plugin is here.

Saturday, October 27, 2007

Checkstyle vs Nonsense code

Recently we have started to use checkstyle to verify our code. Although first intention of checkstyle is to check agreed code conventions, checkstyle is able to check for some known code structures that often mean wrong design of code. This is useful because you can catch common mistakes very early and therefore avoid bugs later.

Among others, one of our checks is that there should not be empty block of code, like catch block.
And then we had our first rule violation. For testing of course we are using JUnit. Standard design of JUnit 3.8 test to verify that certain part of code throws exception looks like this:

try {
performExceptionThrowingOperation(...)
fail();
} catch(ExpectedException excepiton) {
// expected exception
}


Well as you can see catch block is empty, there is no java code in it. And of course checkstyle complained about this.
I see two options here:
  • leave code as it is and do not fix checkstyle violation
  • add nonsense line of code like assertTrue(true)
At the end I have selected third option :), change checkstyle rule so it accepts in the block also plain text e.g. comment (not only java code) and therefore checkstyle violation disappeared.

But now I am getting to the point of my thoughts. As code grows, there will be more and more places where maybe it will be strange (e.g. adding assertTrue(true)) to fix checkstyle violation and not possible to solve it with simple additional configuration of checkstyle rule.

Question is: should we leave checkstyle violation as it is or add strange code of assertTrue(true) style?

My opinion is that we should add strange code and fix checkstyle violation. If we start to leave checkstyle violations open, number of opened checkstyle violations will grow with time and checkstyle violations warnings will loose their intention warning about bad code design. Because if there is long existing list of false checkstyle warnings we may miss the new, but important one. And then, instead of fixing the bug immediately, maybe we will fix it in later testing phases. From my point of view, it is better to have some strange but harmless code lines than to miss one important bug because of long list of existing checkstyle warnings.

If somebody will ever read this :) it would be nice to hear your opinion.

Friday, October 26, 2007

My new blog

So I have setup my blog. Actually, I am not big fan of blogs. I thought I will never have one. I read blogs occasionally and consider myself not being part of blog fever. But then, suddenly I have decided to create blog. I am still not sure what will be in my blog, but maybe I will place some ideas here. Maybe somebody will read my blog. Maybe this will be my first and last blog. Who knows :)
I will see what will come out of this.

Nice evening to everybody.