[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Sewe updated MCHECKSTYLE-229:
-------------------------------------

    Description: 
MCHECKSTYLE-182 is now addressed in 2.12 and produces nice-looking outputs on 
the console. :-)

Alas, {{logViolationsToConsole}} only does so if the output in question is 
indeed a violation, i.e., something that you normally would like to fail the 
build ({{failOnViolation}} is true by default). This is typically not the case 
for things that Checkstyle considers warnings ({{violationSeverity}} defaults 
to {{error}}).

As far as I can see, there is no way to configure the 
{{maven-checkstyle-plugin}} to log things that are not considered violations 
({{consoleOutput}} only prints meaningless "Starting audit" messages, so that 
parameter doesn't offer a workaround).

As far as I can see, a more flexible way would be to have the following three 
properties:

* {{failOnViolation}}
* {{violationSeverity}} (one of {{error}}, {{warning}}, {{info}})
* {{logSeverity}} (one of {{error}}, {{warning}}, {{info}}, {{none}})

This would allow one to drop {{logViolationsToConsole}} (can be emulated by 
setting {{logSeverity}} equal to or lower than {{violationSeverity}}) while at 
the same time enabling the logging of, e.g., non-violation warnings.

What do you think?

  was:
CHECKSTYLE-182 is now addressed in 2.12 and produces nice-looking outputs on 
the console. :-)

Alas, {{logViolationsToConsole}} only does so if the output in question is 
indeed a violation, i.e., something that you normally would like to fail the 
build ({{failOnViolation}} is true by default). This is typically not the case 
for things that Checkstyle considers warnings ({{violationSeverity}} defaults 
to {{error}}).

As far as I can see, there is no way to configure the 
{{maven-checkstyle-plugin}} to log things that are not considered violations 
({{consoleOutput}} only prints meaningless "Starting audit" messages, so that 
parameter doesn't offer a workaround).

As far as I can see, a more flexible way would be to have the following three 
properties:

* {{failOnViolation}}
* {{violationSeverity}} (one of {{error}}, {{warning}}, {{info}})
* {{logSeverity}} (one of {{error}}, {{warning}}, {{info}}, {{none}})

This would allow one to drop {{logViolationsToConsole}} (can be emulated by 
setting {{logSeverity}} equal to or lower than {{violationSeverity}}) while at 
the same time enabling the logging of, e.g., non-violation warnings.

What do you think?


> Enable logging of non-violations
> --------------------------------
>
>                 Key: MCHECKSTYLE-229
>                 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-229
>             Project: Maven Checkstyle Plugin
>          Issue Type: Improvement
>    Affects Versions: 2.12.1
>            Reporter: Andreas Sewe
>
> MCHECKSTYLE-182 is now addressed in 2.12 and produces nice-looking outputs on 
> the console. :-)
> Alas, {{logViolationsToConsole}} only does so if the output in question is 
> indeed a violation, i.e., something that you normally would like to fail the 
> build ({{failOnViolation}} is true by default). This is typically not the 
> case for things that Checkstyle considers warnings ({{violationSeverity}} 
> defaults to {{error}}).
> As far as I can see, there is no way to configure the 
> {{maven-checkstyle-plugin}} to log things that are not considered violations 
> ({{consoleOutput}} only prints meaningless "Starting audit" messages, so that 
> parameter doesn't offer a workaround).
> As far as I can see, a more flexible way would be to have the following three 
> properties:
> * {{failOnViolation}}
> * {{violationSeverity}} (one of {{error}}, {{warning}}, {{info}})
> * {{logSeverity}} (one of {{error}}, {{warning}}, {{info}}, {{none}})
> This would allow one to drop {{logViolationsToConsole}} (can be emulated by 
> setting {{logSeverity}} equal to or lower than {{violationSeverity}}) while 
> at the same time enabling the logging of, e.g., non-violation warnings.
> What do you think?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

Reply via email to