Le dim. 10 nov. 2019 à 00:33, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > > On 9 Nov 2019, at 18:10, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > > > > > > >> On 9 Nov 2019, at 12:23, Gilles Sadowski <gillese...@gmail.com > >> <mailto:gillese...@gmail.com>> 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.
+1 :-) Gilles > — > > 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. *** > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
