You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jeremy Landis (Jira)" <ji...@apache.org> on 2020/01/21 00:32:00 UTC

[jira] [Created] (MCHECKSTYLE-389) MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report

Jeremy Landis created MCHECKSTYLE-389:
-----------------------------------------

             Summary: MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report
                 Key: MCHECKSTYLE-389
                 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-389
             Project: Maven Checkstyle Plugin
          Issue Type: Dependency upgrade
    Affects Versions: 3.1.0
            Reporter: Jeremy Landis


Commit eee0ba1 in CheckstyleReportGenerator.java sets the default 'severity' is set as 'error'.  The suggestion is that it fixes count issues per adjusted comment at that time.  While that may or may not be true, what it does do is incorrectly shut down the entire section of rules aggregation counts in some cases.  The severity only takes into account that specific one to then aggregate.  Selecting just one other than null is going to mess up the logic as implemented here.  This change needs reverted for that one specific change only.  The original issue should be reopened as it was not properly fixed.  The IT tests fails to take into account individual types.  It includes both 'info' and 'error' thus the only reason it even works.

In my test case, I'm using 'mybatis-3'.  I have configured it to use google checks so nothing else setup.  It has 0 info, 3151warnings, and 0 errors.  Switching it to any other value will cause it to only reflect that section.  So using 'info', nothing shows up.  Using 'error' as coded now, nothing shows up.  Using 'warning', it does show up.  Continuing to use null as originally the case, it does show up.

There really was a miscount somewhere, but that was not the right fix.  For my test, I get a miscount of +5 if using 'warning' or the original null.  That is entirely better than nothing. And therefore, the best solution for now is to revert this change.

While my test does not have a combination of issues in 'info', 'warning', and 'error', presumably most do and thus why this was not reported after almost a year since the release of 3.1.0. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)