> On 9 Nov 2019, at 18:10, Alex Herbert <[email protected]> wrote:
>
>
>
>> On 9 Nov 2019, at 12:23, Gilles Sadowski <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> Snip
>>
>> I think that I tried
>> $ mvn -Dcheckstyle.failOnViolation=false test
>>
>> And still it wouldn't run the test (because I had introduced the
>> "System.out" forbidden construct).
>
> Checkstyle is configured to run in the validate phase (right at the start)
> [1]. The default is normally verify. This was copied from commons RNG and
> predates my joining the project.
>
> So this is why you cannot run ‘mvn test’ as it runs checkstyle:check and
> fails you before doing the test.
>
> Now fail on violation is ‘true’ perhaps we should move the check back to
> validate. So you cannot do a 'mvn install' with any checkstyle errors. You
> can also run mvn checkstyle:check to run the goal manually.
>
> [1] http://maven.apache.org/ref/3.6.2/maven-core/lifecycles.html
> <http://maven.apache.org/ref/3.6.2/maven-core/lifecycles.html>
Short answer:
*** Checkstyle ignores command-line user properties in favour of the POM
configuration. ***
(Examples are shown below)
If you want to run tests and use System.out.print to debug stuff (which is a
very reasonable dev action) then:
1. We move checkstyle to run after the test phase (i.e. in verify)
2. You have to put '// CHECKSTYLE: stop all’ or e.g. ‘// CHECKSTYLE: stop
RegexpCheck’ (for System.out violations) in the file you are working on
3. You have to use <failOnViolation>false</failOnViolation> in the POM
(temporarily)
4. You can use an *unset* property from the POM:
-Dcheckstyle.maxAllowedViolations=10
I favour 1 or 4.
Option 1 would have less typing and less to remember.
—
Examples:
Hypothesis: Checkstyle is not using the properties set using -D.
User set properties should override the POM. This is how PMD works. If you make
a violation for PMD and do this:
mvn pmd:check -Dpmd.failOnViolation=true -X
You can see:
[DEBUG] (f) failOnViolation = true
And it fails.
mvn pmd:check -Dpmd.failOnViolation=false -X
You can see:
[DEBUG] (f) failOnViolation = false
And it is allowed.
Trying the same with checkstyle:
mvn checkstyle:check -Dcheckstyle.failOnViolation=true/false
-Dcheckstyle.failsOnError=true/false -X
All variants of true/false show the config from the POM:
[DEBUG] (f) failOnViolation = true
[DEBUG] (f) failsOnError = false
Other properties work as documented:
mvn checkstyle:check -Dcheckstyle.maxAllowedViolations=10
This shows as:
[DEBUG] (f) maxAllowedViolations = 10
And the build passes.
If I remove:
<failOnViolation>true</failOnViolation>
From the checkstyle build plugin configuration in the POM then the command line
user properties work, i.e.
mvn checkstyle:check -Dcheckstyle.failOnViolation=false
[DEBUG] (f) failOnViolation = false
-> PASS
mvn checkstyle:check -Dcheckstyle.failOnViolation=true
[DEBUG] (f) failOnViolation = true
-> FAIL
mvn checkstyle:check
[DEBUG] (f) failOnViolation = true
-> FAIL
The last case uses the default value of true. It is still logged to the
console. The 'effective POM' does not have the <failOnViolation> property
anywhere so checkstyle is logging this even though it has not been configured.
I tried checkstyle plugin 3.0.0 and 3.1.0 (the latest). Same result.
As a control I put <maxAllowedViolations>10</maxAllowedViolations> in the
checkstyle POM configuration. Checkstyle then ignore the same command line
switch that worked before.
*** So it seems checkstyle ignores command-line user properties in favour of
the POM configuration. ***
