[jira] [Commented] (MCHECKSTYLE-389) MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270889#comment-17270889 ] Hudson commented on MCHECKSTYLE-389: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > 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 >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (MCHECKSTYLE-389) MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031653#comment-17031653 ] Hudson commented on MCHECKSTYLE-389: Build succeeded in Jenkins: Maven TLP » maven-checkstyle-plugin » master #47 See https://builds.apache.org/job/maven-box/job/maven-checkstyle-plugin/job/master/47/ > 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 >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > 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)
