I'm stuck with a legacy Java codebase that has THOUSANDS of warnings when you compile it. I would love to actually fix the source of all these warnings, but unfortunately that's not an option at this time at my company (other things like "making new products that generate revenue" are considered higher priority by the people in charge; fancy that).
Now, I could just live with all of these warnings, if it wasn't for the fact that they make it difficult to find actual errors in the output from our continuous build server. The build server just uses an ant call, nothing fancy, but so far I haven't been able to find anything anywhere for how I can modify this call to prevent warning output.
Going through the code and adding a @SuppressWarnings annotation everywhere would work, but it would also be almost as much of a pain as going through and fixing all the warnings' sources. So what I'd really love is if there was just some way I could do:
<javadoc suppressWarrnings="true"
or something similar, to make the javadoc compiler not output all the warning messages. Is anything like this (global javadoc warning disabling) possible?
In Java 8 you can add additionalparam="-Xdoclint:none" to the javadoc task. (Source)
Both the ant task and javadoc tool itself have no way of disabling warnings globally.
One possible workaround I can think of is to run the javadoc task as a separate ant call from the rest of the build. You could use the -logfile argument to ant to redirect the output to a log file rather than the console.
Nowadays some javadoc nonstandard options allow you to avoid an excessive number of errors and/or warnings. Check javadoc's help (execute javadoc -X); the following nonstandard options should be available:
-Xmaxerrs <number>
-Xmaxwarns <number>
-Xdoclint:(all|none|[-]<group>)
-Xmaxerrs sets the maximum number of errors to print
-Xmaxwarns sets the maximum number of warnings to print
-Xdoclint enables or disables specific checks for problems in javadoc comments.
For example, specifying -Xdoclint:none will disable specific checks for most of the problems in javadoc comments; and -Xmaxwarns 1 will limit the number of warnings to 1 (I tried -Xmaxwarns 0, but then it printed all the warnings, so my guess is that 0 means no limit)
Mark's answer sounds good to me, and probably would work great for anyone not using the Cruise Control continuous build system. However, I discovered that for anyone who (like me) is using that system, there's another way.
Cruise control assembles its reports by using several XSLT stylesheets. In our case these stylesheets resided in:
~/applications/cruisecontrol-bin-2.7.3/webapps/cruisecontrol/xsl
but since I didn't setup our installation, I don't know if that's a standard path or not. Regardless, you should be able to find an equivalent directory in your installation. Inside that directory is a file called errors.xsl. To get rid of the warnings you will need to make two changes to that file, both of which involve commenting out existing rules.
Replace:
<xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/>
with:
<!-- <xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/>-->
<xsl:variable name="total.errorMessage.count" select="count($error.messages)"/>
This will make the "error count" be a count of the actual errors, rather than a count of the errors + warnings.
Then, replace:
<xsl:template match="message[@priority='warn']" mode="errors">
<xsl:if test="not(starts-with(text(),'cvs update'))">
<xsl:value-of select="text()"/><br class="none"/>
</xsl:if>
</xsl:template>
with:
<!--<xsl:template match="message[@priority='warn']" mode="errors">
<xsl:if test="not(starts-with(text(),'cvs update'))">
<xsl:value-of select="text()"/><br class="none"/>
</xsl:if>
</xsl:template>-->
This will hide the actual warnings themselves. Alternatively you could always just delete the commented out code, but then you should really back up the file first, in case you ever want to get your warnings back. Also, XSLT ignores any non-XSLT markup, so you could do other things with the warnings besides eliminating them completely: for instance, you could wrap all of the warnings in a DIV, and then use CSS/Javascript to "collapse" the warnings instead of removing them entirely.
Although I ultimately had to discover this solution myself, all of the answers here helped me understand what was going on, so thanks all for the help.
I just discovered there was a slightly better variant of what I described in my previous answer. Instead of editing errors.xsl, edit buildresults.xsl. This file contains a comment:
for traditional cc display of only compile errors and warnings
comment out mode="errors" and uncomment mode="compile" and mode="javadoc"
If you follow that comment's advice (comment out the two lines it mentions and uncomment the one line it mentions) you get the same exact effect, but with compilation errors included.
Why bother with this method over my previous one? Well I think (I really should have tested this better, but I got lazy) that my previous method eats compilation errors; this method preserves them.
