New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix line number in error reporting during manifest validation: #614
Fix line number in error reporting during manifest validation: #614
Conversation
Test Results 237 files - 6 237 suites - 6 51m 6s ⏱️ - 3m 13s For more details on these failures, see this check. Results for commit adcbe18. ± Comparison against base commit 57007dd. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The variable names like t1,t2,hdr can be improved
- StringTokenizer is legacy, split should be preferred
- Also a short comment on what you are trying to achieve
In some cases manifest validation takes place in the OSGI layers without obtaining the erroneous line number, as is the case with bundle description validation, thereby displaying it on line 1. This may lead to confusion regarding line number. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The declaration at line 149 could be moved down. Update license year if required.
split could be renamed as splitArray. Also one liner comment on what you are doing.
Hi @vik-chand , |
IHeader header = null; | ||
header = getHeader(lastString); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IHeader header = null; | |
header = getHeader(lastString); | |
IHeader header = getHeader(lastString); |
Please rebase wrt latest. |
The plug-in manifest is validated in two phases: i) when it is first loaded, ii) when the manifest is inline edited. In the former case, the validation is carried out in OSGI layers, and the exception caught in the pde modules with no bearing on the faulty line number, in case of issues. This commit tries to parse the exception message in a best effort basis, extracts the header that is subjected for the fault and obtains the line number of the header. It falls back on line 1, in case of parse error.
ced50ec
to
adcbe18
Compare
The plug-in manifest is validated in two phases: i) when it is first loaded, ii) when the manifest is inline edited. In the former case, the validation is carried out in OSGI layers, and the exception caught in the pde modules with no bearing on the faulty line number, in case of issues.
This commit tries to parse the exception message in a best effort basis, extracts the header that is subjected for the fault and obtains the line number of the header. It falls back on line 1, in case of parse error.
Fixes: #613