yetus-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Vary (JIRA)" <>
Subject [jira] [Created] (YETUS-488) Checkstyle reports new error if the file still longer than expected
Date Wed, 15 Feb 2017 14:52:41 GMT
Peter Vary created YETUS-488:

             Summary: Checkstyle reports new error if the file still longer than expected
                 Key: YETUS-488
             Project: Yetus
          Issue Type: Improvement
          Components: Test Patch
    Affects Versions: 0.4.0
            Reporter: Peter Vary
            Assignee: Peter Vary
            Priority: Minor

Given a java source file which is originally longer than the checkstyle defined value then
we get the following warning every time the length changes and we run the checkstyle plugin:
./beeline/src/java/org/apache/hive/beeline/ warning: File length is 2,373 lines
(max allowed is 2,000).

The problem is, that the checkstyle output is changed:
./beeline/src/java/org/apache/hive/beeline/ warning: File length is 2,373 lines
(max allowed is 2,000).
./beeline/src/java/org/apache/hive/beeline/ warning: File length is 2,365 lines
(max allowed is 2,000).
Since the {{checkstyle_calcdiffs}} does not find the new line in the original output, it marks
it as a new error, and gives -1 to the result of the checkstyle plugin.

This is true for every error message where there is a number in the text. Not exhaustive examples
are below:
- Line length
- Row length
- Function length
- Number of attributes
- Indentation

I think we should be reluctant to give -1 without a reason so it would be good to remove these

I have yet to find the ideal solution for the issue:
- An easy patch could be to remove the numbers from files before the diff (note: it does not
effect the final diff-checkstyle-<MODULE>.txt output messages). This would mean that
the warning will give -1 only the first time when the error text is occurred, and will not
give -1 if the numbers are changed, like
-- File become shorter, but still longer than expected
-- File become even longer
-- Indentation changed but still problematic
- A more sophisticated patch could do this only for specific errors, or even check the value
and give error when the line length grow.

To be honest, I think the second solution would complicate the code too much, and make it
dependent on the specific checkstyle messages, so I do not like it.

I am even hesitant about the first one, because the change I introducing with it might have
unwanted consequences.

Do anyone has better ideas? I would be happy to implement them, if someone points me to the
right direction :D


This message was sent by Atlassian JIRA

View raw message