Hmm, interesting. I followed your example steps: and now I get a Jenkins maven job with Checkstyle warnings from Scala

[CHECKSTYLE] Parsing file /Users/hafner/Development/jenkins/jobs/JENKINS-17287/workspace/subcut/scalastyle-output.xml
[CHECKSTYLE] Successfully parsed file /Users/hafner/Development/jenkins/jobs/JENKINS-17287/workspace/subcut/scalastyle-output.xml of module subcut with 353 unique warnings and 0 duplicates.
[CHECKSTYLE] Im pom.xml wurde keine Dateikodierung festgelegt, daher wird die vorgegebene Kodierung UTF-8 des aktuellen Systems verwendet. Damit wird der Build abhängig vom System, auf dem er läuft (siehe auch <a href="http://docs.codehaus.org/

Maybe something is broken in your configuration. I'll add my configuration as screenshot...

You mean that it works for you ???

Something else must be going on. I've made sure to have EXACTLY the same configuration. And yet it doesn't make a difference. I've got load of Java related Checkstyle warnings. But none for Scala files.

This is the instruction I run:

clean package jxr:jxr pmd:cpd pmd:pmd checkstyle:checkstyle scalastyle:check findbugs:findbugs -DskipTests=true -Djava.awt.headless=false

Maybe because I'm also running CheckStyle ? Or because it is a multi-module project ? The out files would be scattered in the different module directories.

Ah, I see. Yes, the reason is that you also run CheckStyle. For all of my plugins I'm checking if there is already a result present. If there is one there then I'm skipping the step. You can check this by running the goals in the opposite order: mvn scalastyle:check checkstyle:checkstyle. Then you will get Scala warnings but no Java warnings.

That means I need to run the checkstyle reporter multiple times. I.e. in the end there will be multiple Checkstyle results available for a build.

Indeed, that's it. It works when running only ScalaStyle.

Problem is ... it's a Java AND Scala project.

Wouldn't it be easier to have a ScalaStyle plugin instead ? Now those two coincide more or less. And their data can be merged. But how long will it remain that way ?

Anyway, any idea what I might try to actually merge the data ? I thought I was already doing that. But it looks like the results of one is erased.

The problem only occurs with the maven project type, freestyle project should already pick both files. I think it is not possible to merge these files since the maven build type invokes Checkstyle directly after the goal has been finished.

An additional plug-in is also somewhat an overkill, since the parser still is the same.

There are two possibilities:

1. Add a new reporter class responsible for ScalaStyle (This is then an additional post build step with separate configuration). Then there will be two results (and links) available, one for Java and one for Scala.
2. Aggregate the results. I'm not sure how easy that approach is since I need to load and discard the first action...

I am already doing (2) but wasn't aware one *Style would erase the results of the other one. So I might ask both to dump into separate files and merge manually. I'll have a go at that. At least now the cause is known. However, I have no clue as to how durably fix this really. I guess apply (1).

What I am surprised though is why the results are erased at the first place. How come CheckStyle erases a file named scalastyle-output.xml ?

My plug-in does not erase anything Checkstyle creates the checkstyle.xml file that is read by my plugin afterwards. After that, Scalastyle creates scalastyle.cml. This file is not read anymore since there is already a result available. So it won't help to merge the results. With the maven project type, you can change the file names of the results since these information is read from the pom.

Would it help to run the two in separate invocations ? First 'mvn scalastyle:check' followed by 'mvn checkstyle:checkstyle'. As a workaround of course.

I have no clue how to durably fix this - as I never wrote a Jenkins- or Maven plugin.

Released in 5.0.0-beta2.