This is a mini-project in which we try to package sensible defaults for source code quality control profiles. The aim of this project is not to define a global styleguide (although somehow indirectly it does), but to provide you Maven-ready setups for some of the major quality/style-checking tools.
Using the artifacts of this project you can quickly integrate checks in the Maven build of your project without having to invest too much time setting them up.
The tools we currently support are:
Opinion - everyone has one: You might have noticed on the above paragraphs we mentioned "sensible defaults". We understand perfectly that what one finds sensible may be totally insensible to someone else and, quite literally, there is no one-size-fits-all approach here. If you find a rule too restrictive (and can justify it), or if you find an ignored rule that needs to be enforced (and can justify it), please use the Issues Tracking of the project to let us know.
The artifacts of this project are published in Maven Central, so you can use it in your project as any other dependency.
For PMD we provide a ed-qp-pmd-ruleset.xml
ruleset that can be
used in your project's build configuration. The ruleset comes with all
Java rules enabled except the ones documented in the ruleset file itself.
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>${maven-pmd-plugin.version}</version>
<configuration>
<rulesets>
<ruleset>ed-qp-pmd-ruleset.xml</ruleset>
</rulesets>
<printFailingErrors>true</printFailingErrors>
<linkXRef>false</linkXRef>
<sourceEncoding>UTF-8</sourceEncoding>
</configuration>
<executions>
<execution>
<id>pmd</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.eurodyn.qp</groupId>
<artifactId>ed-qp-pmd</artifactId>
<version>${ed-qp.version}</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
Gotcha: The above configuration will fail your build in case PMD errors exist,
which is a good thing on a new project. However, if you want to introduce
PMD checks on an existing project where you might not have the luxury of
time to correct all mistakes at once, you can add
on the <configuration>
section <failOnViolation>false</failOnViolation>
.
For Checkstyle we provide a ed-qp-checkstyle.xml
configuration file
following the Google Java Style Guide
taken from Checkstyle project.
Any rule that may be disabled on the above configuration template is
documented on the configuration file.
Note to flame-warlords: We understand there is an endless debate between Google style vs Apache style, tabs vs spaces, etc. but, we believe, the purpose of a Style Guide is not to declare "the best" styling for your source code but to ensure that the source within your project (or entire organisation) looks coherent. So, just pick a style guide you feel comfortable with and stick with it; that is what we did here.
Style as you type: Are you using IntelliJ IDEA or Eclipse IDE? You can set your default styling to Google's Style Guide here.
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${maven-checkstyle-plugin.version}</version>
<executions>
<execution>
<id>checkstyle</id>
<phase>validate</phase>
<configuration>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<configLocation>ed-qp-checkstyle.xml</configLocation>
</configuration>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.eurodyn.qp</groupId>
<artifactId>ed-qp-checkstyle</artifactId>
<version>${ed-qp.version}</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
Gotcha: The above configuration will fail your build in case Checkstyle
errors exist, which is a good thing on a new project. However, if you want
to introduce checks on an existing project where you might not have the
luxury of time to correct all mistakes at once, you can add on the
<configuration>
section <failsOnError>false</failsOnError>
.
FindBugs does not require a specially crafted configuration (at least, for now). You can simply integrate it as part of your Maven build following the instructions below.
...
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>${findbugs-maven-plugin.version}</version>
<executions>
<execution>
<id>findbugs</id>
<goals>
<goal>check</goal>
</goals>
<configuration>
<includeTests>true</includeTests>
<sourceEncoding>UTF-8</sourceEncoding>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
Gotcha: The above configuration will fail your build in case FindBugs
errors exist, which is a good thing on a new project. However, if you want
to introduce checks on an existing project where you might not have the
luxury of time to correct all mistakes at once, you can add on the
<configuration>
section <failOnError>false</failOnError>
.
For OWASP MDC we provide a customised suppression list to exclude known conflicts (such as the QLACK Fuse module).
...
<plugins>
...
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>${dependency-check-maven.version}</version>
<configuration>
<suppressionFile>owasp-suppression.xml</suppressionFile>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.eurodyn.qp</groupId>
<artifactId>ed-qp-owasp</artifactId>
<version>${ed-qp.version}</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
Gotcha: The above configuration will fail your build in case OWASP
errors exist, which is a good thing on a new project. However, if you want
to introduce checks on an existing project where you might not have the
luxury of time to correct all mistakes at once, you can add on the
<configuration>
section <failOnError>false</failOnError>
.