You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Robert Scholte (JIRA)" <ji...@apache.org> on 2017/09/28 19:59:00 UTC

[jira] [Commented] (MCHECKSTYLE-341) Introduce an expectedViolation flag

    [ https://issues.apache.org/jira/browse/MCHECKSTYLE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16184750#comment-16184750 ] 

Robert Scholte commented on MCHECKSTYLE-341:
--------------------------------------------

I don't think Maven is the proper tool to solve this. As you mention yourself, it now requires discipline from developers to always adjust this seting in the pom. I don't think we should use the pom for that reason.
Maven is aware of the current and at most the previous build. What you are looking for is a trend of violations. I think you should try to solve this with usage of CI / CQM servers. AFAIK SonarQube has very good support for it.

https://maven.apache.org/code-quality-management.html
https://maven.apache.org/continuous-integration.html

> Introduce an expectedViolation flag
> -----------------------------------
>
>                 Key: MCHECKSTYLE-341
>                 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-341
>             Project: Maven Checkstyle Plugin
>          Issue Type: New Feature
>          Components: checkstyle:check
>    Affects Versions: 2.17
>            Reporter: Tibo
>            Priority: Minor
>
> We are trying to fix our tech debt step by step using the maxAllowedViolation flag and reducing the number slowly.
> We have 400+ maven module in our project and developer never update this flag, So basically when someone is fixing checkstyle error without updating the flag, it leaves room for another developer to introduce new errors...
> I would like an expectedViolation flag just to force people who are fixing issues to also update the count... It could be called "expectedViolation". The difference with the maxAllowedViolation flag is that this one would also fail when the number of actual violation is less than the "expectedViolation" flag.
> I believe the maxAllowedViolation should have been an expectedViolation from the start. I don't believe anyone wants to leave room for violation, you just want, for an existing project, to explicitly specify the current number of violation and disallow through pull request the number to go up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)