java 如何在 javadoc 编译期间抑制警告（代码库范围内）？

How can I suppress warnings (codebase-wide) during javadoc compilation?

提问by machineghost

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).

我被一个遗留的 Java 代码库困住了，当你编译它时，它有成千上万的警告。我很想真正修复所有这些警告的来源，但不幸的是，这在我的公司目前不是一个选择（其他诸如“制造能产生收入的新产品”之类的事情被负责人认为是更高的优先事项；想象一下） .

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.

现在，我可以忍受所有这些警告，如果不是因为它们很难在我们的持续构建服务器的输出中找到实际错误。构建服务器只使用了一个 ant 调用，没什么特别的，但到目前为止，我还没有在任何地方找到任何关于如何修改这个调用以防止警告输出的信息。

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:

浏览代码并在任何地方添加@SuppressWarnings 注释都可以，但它也几乎与浏览和修复所有警告的来源一样痛苦。所以我真正喜欢的是，如果有一些我可以做的方法：

<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?

或类似的东西，使 javadoc 编译器不输出所有警告消息。这样的事情（全局 javadoc 警告禁用）可能吗？

采纳答案by Robert Tupelo-Schneck

In Java 8 you can add additionalparam="-Xdoclint:none"to the javadoctask. (Source)

在 Java 8 中，您可以添加additionalparam="-Xdoclint:none"到javadoc任务中。 （来源）

回答by Robert Tupelo-Schneck

Try the -quiet flag.

试试 -quiet 标志。

回答by Mark

Both the ant task and javadoc tool itself have no way of disabling warnings globally.

ant 任务和 javadoc 工具本身都无法全局禁用警告。

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.

我能想到的一种可能的解决方法是将 javadoc 任务作为独立于构建其余部分的单独 ant 调用运行。您可以使用 ant 的 -logfile 参数将输出重定向到日志文件而不是控制台。

回答by Jorge Campins

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:

如今，一些 javadoc 非标准选项允许您避免过多的错误和/或警告。查看javadoc的帮助（执行javadoc -X）；应提供以下非标准选项：

-Xmaxerrs <number>
-Xmaxwarns <number>              
-Xdoclint:(all|none|[-]<group>)

-Xmaxerrssets the maximum number of errors to print -Xmaxwarnssets the maximum number of warnings to print -Xdoclintenables or disables specific checks for problems in javadoc comments.

-Xmaxerrs设置要打印-Xmaxwarns的最大错误数设置要打印 的最大警告数 -Xdoclint启用或禁用对 javadoc 注释中问题的特定检查。

For example, specifying -Xdoclint:nonewill disable specific checks for most of the problems in javadoc comments; and -Xmaxwarns 1will 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)

例如，指定-Xdoclint:none将禁用对 javadoc 注释中的大多数问题的特定检查；并将-Xmaxwarns 1警告数量限制为 1（我尝试过-Xmaxwarns 0，但随后它打印了所有警告，所以我的猜测是 0 表示没有限制）

回答by machineghost

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.

Mark 的回答对我来说听起来不错，并且可能对不使用 Cruise Control 连续构建系统的任何人都非常有用。但是，我发现对于使用该系统的任何人（如我），还有另一种方法。

Cruise control assembles its reports by using several XSLT stylesheets. In our case these stylesheets resided in:

Cruise Control 使用多个 XSLT 样式表来组合其报告。在我们的例子中，这些样式表位于：

~/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.

但由于我没有设置我们的安装，我不知道这是否是标准路径。无论如何，您应该能够在安装中找到等效的目录。在该目录中有一个名为 errors.xsl 的文件。要消除警告，您需要对该文件进行两项更改，这两项更改都涉及注释掉现有规则。

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.

这将隐藏实际的警告本身。或者，您可以随时删除注释掉的代码，但是您应该首先真正备份文件，以防您想恢复警告。此外，XSLT 会忽略任何非 XSLT 标记，因此除了完全消除警告之外，您还可以对警告执行其他操作：例如，您可以将所有警告包装在一个 DIV 中，然后使用 CSS/Javascript 来“折叠”警告而不是完全删除它们。

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.

虽然我最终不得不自己发现这个解决方案，但这里的所有答案都帮助我了解了发生了什么，所以感谢大家的帮助。

回答by machineghost

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:

我刚刚发现我在之前的答案中描述的内容有一个稍微更好的变体。不要编辑errors.xsl，而是编辑buildresults.xsl。该文件包含一条评论：

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.

为什么要在我以前的方法上使用这种方法？好吧，我认为（我真的应该更好地测试这个，但我很懒）我以前的方法会吃编译错误；这种方法保留了它们。