Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
Description
I'm trying to use the Eclipse Java Compiler parser to analyze warnings in log files from a headless Eclipse PDE build. Unfortunately, I only get five matches out of a system which I know contain many hundreds of warnings. I have looked at the regexp in the parser class and it might be the ending bracket that gives me the erratic behaviour, although I must admit I cannot decipher exactly what the purpose of that bracket is. An example from my logs will illustrate this better. This excerpt will actually log a warning with the plugin (paths abbreviated for readability):
3. WARNING in /srv/hudson/workspace/.../ValidationProblemsReporter.java (at line 38) (IStatus[]) results.toArray(new IStatus[results.size()]), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Type safety: The method toArray(Object[]) belongs to the raw type List. References to generic type List<E> should be parameterized
whereas this log entry will not:
4. WARNING in /srv/hudson/workspace/.../Validator.java (at line 7) import org.eclipse.core.resources.ResourcesPlugin; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The import org.eclipse.core.resources.ResourcesPlugin is never used
The former entry actually includes an ending bracket and the warning will appear in Hudson like this:
File: ValidationProblemsReporter.java, Line: 38, Type: Eclipse Java Compiler, Priority: Normal ) belongs to the raw type List. References to generic type List should be parameterized
Now, I cannot be entirely sure that this is a bug or actually some feature which I simply cannot get to work properly, but to me it certainly does not look like the expected output.
Attachments
Activity
Field | Original Value | New Value |
---|---|---|
Attachment | logs.txt.gz [ 19387 ] |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Workflow | JNJira [ 136522 ] | JNJira + In-Review [ 204084 ] |
Do you have some more examples? I've not written the Eclipse parser and adding some additional examples in the existing Unit tests will reduce the risk of breaking something before I make such a change...