Code changed in hudson
User: : drulli
Path:
trunk/hudson/plugins/warnings/src/main/java/hudson/plugins/warnings/parser/DoxygenParser.java
trunk/hudson/plugins/warnings/src/test/java/hudson/plugins/warnings/parser/DoxygenParserTest.java
trunk/hudson/plugins/warnings/src/test/resources/hudson/plugins/warnings/parser/issue6971.txt
http://jenkins-ci.org/commit/33059
Log:
[FIXED JENKINS-6971]: doxygen 1.7.1 warnings are not logged

Integrated in Hudson Plug-ins (Compile) #29
[FIXED JENKINS-6971]: doxygen 1.7.1 warnings are not logged

I'm seeing the same issue with the warning plugin 3.22 and oxygen 1.7.4. The issue was fixed in the warning plugin version 3.8 so it should also work with version 3.22.

Hmm, the unit tests are still passing...

Is your output similar to

/home/user/myproject/helper/LCPcalc.cpp:479:warning: the name `lcp_lexicolemke.c' supplied as the second argument in the \file statement is not an input file
/home/user/myproject/helper/SimpleTimer.h:19:error: Unexpected character `"'

Can you please attach a sample?

Quick answer and I received no mail about. I must change my notification settings.
My output is for warnings:
.../XmlParser.h:357: warning: Member getInternalParser() (function) of class XmlParser is not documented.
There are no errors, only warnings.
And later on I see in my Jenkins log:
[WARNINGS] Parsing warnings in console log with parsers [Doxygen, MSBuild]
[WARNINGS] Doxygen : Found 0 warnings.
[WARNINGS] MSBuild : Found 30 warnings.
Publishing Doxygen HTML results...
Thanks a lot!.

You need to add you as a watcher to get notifications.

Thanks for the tip. I was looking for that option in my profile and hadn't found it.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/parser/DoxygenParser.java
src/test/java/hudson/plugins/warnings/parser/DoxygenParserTest.java
src/test/resources/hudson/plugins/warnings/parser/issue6971.txt
http://jenkins-ci.org/commit/warnings-plugin/b06a0558ce00a8d6ae23dff6657eb6b7263b7fbf
Log:
JENKINS-6971 Correctly parse relative paths in Doxygen error messages.

Integrated in plugins_warnings #334
JENKINS-6971 Correctly parse relative paths in Doxygen error messages.

Ulli Hafner :
Files :

• src/test/java/hudson/plugins/warnings/parser/DoxygenParserTest.java
• src/main/java/hudson/plugins/warnings/parser/DoxygenParser.java
• src/test/resources/hudson/plugins/warnings/parser/issue6971.txt

Apart from relative paths we also have fairly strange paths such as these
P:/Integration/DjRip/djrip/workspace/libraries/xml/XmlMemoryEntityResolver.h:39: warning: Member XmlMemoryEntityMapEntry (typedef) of class XmlMemoryEntityResolver is not documented.
I guess using funny units like P may not be included in the regular expression.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/parser/BuckminsterParser.java
src/main/java/hudson/plugins/warnings/parser/Gcc4CompilerParser.java
src/test/java/hudson/plugins/warnings/parser/DoxygenParserTest.java
src/test/resources/hudson/plugins/warnings/parser/issue6971.txt
http://jenkins-ci.org/commit/warnings-plugin/7a63d66d7162cebbb3b95e07f0c1bba671b5ab5f
Log:
[FIXED JENKINS-6971] Added another unit test for Doxygen parser.

Seems that your complex path is already supported

Integrated in plugins_warnings #335
[FIXED JENKINS-6971] Added another unit test for Doxygen parser.

Ulli Hafner :
Files :

• src/test/resources/hudson/plugins/warnings/parser/issue6971.txt
• src/main/java/hudson/plugins/warnings/parser/BuckminsterParser.java
• src/main/java/hudson/plugins/warnings/parser/Gcc4CompilerParser.java
• src/test/java/hudson/plugins/warnings/parser/DoxygenParserTest.java

One last question. I should get the latest version and obtain a Jenkins plugin and test it in my installation, or I'd better wait until a release comes out which includes these changes?

Testing the version from http://ci.jenkins-ci.org/job/plugins_warnings/335/ would be good. (I'm not sure but maybe you need also the latest snapshot of analysis-core from http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-core/). The next release still needs some time and other fixes.

I tested with the hpi present in the link you supplied. It does not work. And I think I know why. This is running under Windows and uses NANT to launch doxygen, with the exec NANT task.
So the actual line is:
[exec] P:/Integration/DjRip/djrip/workspace/foundation/include/graph/graph.h:56: warning: Member end() (function) of class graph_stl::Graph is not documented.
[exec] P:/Integration/DjRip/djrip/workspace/foundation/include/graph/graph.h:59: warning: Member operator[](int i) (function) of class graph_stl::Graph is not documented.
I guess the [exec] is confusing the parser of the regular expression. Apologies for not pasting the whole line as example. I failed to see the whole line was important.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/WarningsPublisher.java
src/main/java/hudson/plugins/warnings/parser/AntJavacParser.java
src/main/java/hudson/plugins/warnings/parser/DoxygenParser.java
src/main/java/hudson/plugins/warnings/parser/Gcc4CompilerParser.java
src/main/java/hudson/plugins/warnings/parser/MsBuildParser.java
src/main/java/hudson/plugins/warnings/parser/RegexpParser.java
src/test/java/hudson/plugins/warnings/parser/ParserRegistryTest.java
src/test/resources/hudson/plugins/warnings/parser/issue6971.txt
http://jenkins-ci.org/commit/warnings-plugin/be59fc0e2c84d4eeed751a324de7f4a1356a8a0f
Log:
[FIXED JENKINS-6971] Added optional ant task prefix to regexp.

Integrated in plugins_warnings #337

Tried this with the latest official version of static code analysis plugins (1.33) and warnings plugins #337 (warnings-3.25-SNAPSHOT.hpi), it crashed when evaluating the regular expression:
[WARNINGS] Parsing warnings in console log with parsers [Doxygen, MSBuild]
FATAL: null
java.lang.StackOverflowError
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$Curly.match0(Unknown Source)
at java.util.regex.Pattern$Curly.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$BmpCharProperty.match(Unknown Source)
at java.util.regex.Pattern$GroupHead.match(Unknown Source)
at java.util.regex.Pattern$Loop.match(Unknown Source)
at java.util.regex.Pattern$GroupTail.match(Unknown Source)
at java.util.regex.Pattern$Curly.match0(Unknown Source)
at java.util.regex.Pattern$Curly.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$CharProperty.match(Unknown Source)
at java.util.regex.Pattern$BmpCharProperty.match(Unknown Source)
at java.util.regex.Pattern$GroupHead.match(Unknown Source)
....

Might be related to JENKINS-7178 (JDK bug). Which JRE are you using?

After installing Jenkins with the Windows installer in a pre-production server, the JDK used by Jenkins is specified in the jenkins.xml file.
And it seems I'm using the jre that sits there.
Typing java -version yields:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode)
In the JENKINS-7178 you suggest to use JDK 7 so I can try that and tell Jenkins in the jenkins.xml to use the external installed JDK 7.

I made Jenkins to use the JDK 7 version that can be downloaded from Oracle. The crash also happens. Note that in the production server, which uses the JDK bundled with Jenkins, I installed yesterday version 335 of the plugins warning and it did not crash when parsing the Doxygen warnings. So it seems the JDK 6 or 7 don't like the regular expression which includes matching "[exec]".

OK, thanks for checking that... I think I need to download JDK7 as well and run my testcase for JENKINS-7178 again. If this test case fails then I will reopen that bug in JDK.

In the meantime I think we need to check why the regular expression is sooo complicated (this code was provided by a volunteer). Maybe this regular expression can be simplified. Are you interested in experimenting with the current expression?

Here is the code: https://github.com/jenkinsci/warnings-plugin/blob/master/src/main/java/hudson/plugins/warnings/parser/DoxygenParser.java

I´d like this to work for Windows. We're also analysing the Doxygen output in Linux and thanks to the absence of the "[exec]" beginning of the line, it works. I'm interested in experimenting with the current expression or with a modified version of it

Seems that there still is some work to do.

What do you expect me to do? Create a small Java console application and copy pasting the regexp code and matching our doxygen lines? Or something else?

That depends on much time you have

The optimal solution would be to check out the source code and try to improve the regular expressions in the current DoxygenParser class. Do you already have some Java experience? An option would be to split the parser into two parts: the first one scans single line warnings and the second one multi-line ones.

If that is not possible, you can attach at least some (raw) warning logs that are typical. Then I can uses these to improve the parsers...

Unfortunately I was not notified that you had answered my last question. In the meantime, I have found a good workaround for this bug. Doxygen allows you to designate a file so that the doxygen output will be written there. But the normal stderr also works when you specify this file. These are the details:

1. The WARN_LOGFILE tag can be used to specify a file to which warning
2. and error messages should be written. If left blank the output is written
3. to stderr.

WARN_LOGFILE = doxygen.output

Then in the warnings plugin instead of having the MSBuild and doxygen parsers for the console you just specify the MSBuild parser.
In the "Scan workspace files" section of the Warnings plugin configuration, you specify the doxygen.output file with the doxygen parser.
It works like a charm. And you don't need to modify the regular expression to take into account the "[exec]" stuff that running doxygen through NAnt adds.

Ok, then I'm closing this issue.