views:

731

answers:

4

I have a project that consists of several Maven modules which are all children of a parent module. I have the parent set up to use checkstyle and the child modules all inherit this behaviour correctly. I would like all the child modules to use the parents suppression file defined in its plugin. I define a property checkstyle.suppression which is used in the checkstyle plugin

<properties>
  <checkstyle.suppressions>${basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions>
</properties>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>2.2</version>
    <configuration>
      <configLocation>config/sun_checks.xml</configLocation>
      <suppressionsLocation>${checkstyle.suppressions}</suppressionsLocation>
      <suppressionsFileExpression>${checkstyle.suppressions}</suppressionsFileExpression>
    </configuration>
  </plugin>
</plugins>

Which works fine for the parent but all the child modules try to find the file in their basedir which does make sense.
I am sure there must be a simple solution I am missing but is there a way to define this location so that all the child modules will use the parent location without hard coding it?

A: 

Have you tried defining the property like this in the parent pom or redefining it in the childrens?

 <properties>
   <checkstyle.suppressions>${parent.project.basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions>
 </properties>
rodrigoap
I did try this but as it always returns null, perhaps because it is declared on the parent only. <br>When I run the maven using -X (debug) I can see that this value is null.
Shawn
A: 

If the parent isn't going to run checkstyle, you might just be able to rewrite it to

<properties>
  <checkstyle.suppressions>..\..\src\checkstyle\suppressions.xml</checkstyle.suppressions>
</properties>

Or something like this. Or you could put something in settings.xml to point everything to an system wide config directory.

While it might not be recommended, you can have use a boot-strap or set-up project or task put a copy of the suppressions.xml file to a location specified by a property in settings.xml and then always refer to it by that locations.

sal
The reasons this won't work for me isI don't declare the checkstyle plugin in the child modules (maybe I should) so this property is set in the parent and the child modules can have different directory depths:so I could have parent > webservices > cxf > ssoand say parent > security > ssoI could define the plugin in each module and use this notation but I woudl prefer not to. I could define it in the settings.xml but this restricts us to checking out to a pre-defined location or remembering to change it to where you check the source out to.
Shawn
The workaround we did for an xml license file was to have users copy it to $home/.m2/license.xml and have the setting file point to that file. We also used a set-up project that downloaded that file and put it into the $home/.m2/ directory. That might help.
sal
+1  A: 

The plugin's documentation mentions a similar use case here: http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html

Kutzi
+6  A: 

The answers above are dangerous. I maintain that each project should be self contained, so referring to files external to it is going to break a build sooner or later. Checkstyle can take a url for the file but that means you can't build offline. A better approach is to package your file (can also add pmd.xml) into a jar and then add that jar to the classpath of the checkstyle (or pmd) plugin. I have an example of it here and more about overridding a plugin classpath here

Brian Fox
Thanks Brian for this resource, I will bookmark it for future use: This is just what I needed as I didn't want to define a fixed location for any of the resources due to the fact that developers can check it out to any location and build machines will also have different locations and file systems. As in the example the resources are bundled up using the assembly plugin and then that is unziped and used in the child modules. Thanks
Shawn
+1 you should avoid having any configurations relying on the local file system structure
Rich Seller