Using the same suppression filter for Checkstyle in Eclipse and Maven

Code Quality

We all agree—code quality is an important component of the development process. And we all agree—less times is spent for code quality than it should be. According to [1] code has to be written with an eye on readability which influences the costs in development process directly. Kent argues, that the easier your code can be understood by another developer, the faster he or she could be productive in bug fixing, extending or refactoring. And: the easier your code can be understood, the less new bugs are implemented.

There are some great tools out there, which could help to improve code quality, like Checkstyle [2], Findbugs [3] and PMD [4]. Checkstyle is a static code analysis tool which—unlike e.g. FindBugs—works on the source code directly. You can use some pregiven rule sets or define your own ones, you are able to change the rules themselves (e.g. adopt thresholds) and you are able to use them in Eclipse via the plugin Eclipse-CS [5] and in Maven (using the Maven Checkstyle Plugin [6]).

The problem

Now let us assume, that you are working in a software project with more than just you as a developer and you are using Checkstyle. It’s obvious that the rule set should be shared. And if you are using a suppression filter, Eclipse and Maven—you’re in trouble.

So let me summarize the boundary values quickly:

  • You are working with Eclipse and Eclipse-CS
  • You are using Maven in your buildsystem
  • You have your Checkstyle rules in a file “checkstyle.xml” which lies inside your project (here in the folder ‘checks’)
  • You also have a configuration file “checkstyle-suppressions.xml” holding suppression rules inside your project (in the folder ‘checks’)
  • (Here’s the problem:) You want to use THOSE two files for Eclipse AND for Maven

So your workspace might look like this:

How your workspace might look like

By using M2Eclipse and checkstyle-m2eclipse [7] you might be out of trouble (I haven’t tried it yet). According to the Checkstyle’s website these tools will do the synchronizing for you.

I also want to mention, that there’s no problem if you are using the suppression file just in Maven—simply add the following to your pom.xml [8]:


And configuring Eclipse for using the suppressions could be done in the Checkstlyle-Plugin directly (e.g. select “Window” → “Preferences” → “Checkstyle” in your IDE) or in the checkstyle.xml. Here you simpy add:

<module name="SuppressionFilter">
    <property name="file" value="${config_loc}/checkstyle_suppressions.xml"/>

Note that the place holder “${config_loc}” is a build-in variable of Eclipse-CS and will point to the same directory where the checkstyle.xml lies. So for Eclipse that’s all—the suppression file will be used as soon as you do a new scan with Checkstyle. But if you call ‘mvn checkstyle:checkstyle’ (assuming you have added the checkstyle-plugin to your pom.xml like above) this will fail due to the fact that Maven doesn’t know ${config_loc}.

The solution

But there’s a way to let Maven know—and that’s also the solution of the given problem. Add the SuppressionFilter to the checkstyle.xml as shown above. Then add to your pom.xml:


The point is you are using a property file, declared by propertyLocation. This file (here lets Maven bind the variable ${config_loc} to the local directory ‘checks’ in which our checkstyle-suppressions.xml lies. The content of is simply one single line:


Rerun Maven and a Checkstyle scan in Eclipse—now you are using the same rule set and the same suppressions.


  1. [1] Beck, Kent. 2010. Implementation Patterns. Addison-Wesley
  2. [2]
  3. [3]
  4. [4]
  5. [5]
  6. [6]
  7. [7]
  8. [8]

Rolf Engelhard


Comments (10) Write a comment

  1. Ahh finally. This was killing me. You do have an inconsistency with config_loc vs. file_loc (config_loc is the correct value, from the XML example).


    • Shame on me… thank you for reporting! I replaced all occurences of ‘file_loc’ with ‘config_loc’.


  2. It doesn’t seem to work for multi-module projects (for example: project P with main POM.xml contains module module1, module2, …)?
    Described configuration works for a build of a main POM.xml but the overall build fails when it steps into building modules (fails on a first module), because it evaluates the ${basedir} to a different directory (now relative to a module not the main project) and cannot find CS config files any more.

    Any ideas for a solution?


  3. Many thanks for this Eclipse/Maven/Checkstyle post. It was exactly what i needed


  4. This is a brilliant solution! Exactly what I was looking for. Thank you for saving me a lot of time and frustration! 🙂


Leave a Reply

Required fields are marked *.