Как я могу подавить предупреждения (кодовые базы) во время компиляции javadoc?

Я застрял с устаревшей кодовой базой Java, у которой есть ТЫСЯЧИ предупреждений при компиляции. Мне бы очень хотелось исправить источник всех этих предупреждений, но, к сожалению, это не вариант в настоящее время в моей компании (другие вещи, такие как "создание новых продуктов, которые приносят доход", считаются более приоритетными для ответственных лиц,.

Теперь я мог бы жить со всеми этими предупреждениями, если бы не факт, что они затрудняют поиск фактических ошибок в выходе с нашего сервера непрерывной сборки. Сервер сборки просто использует вызов ant, ничего необычного, но до сих пор я нигде не мог найти что-либо, чтобы изменить этот вызов, чтобы предотвратить вывод предупреждений.

Прохождение кода и добавление аннотации @SuppressWarnings повсюду будут работать, но это также будет почти такой же болью, как прохождение и фиксация всех источников предупреждений. Так что мне действительно понравилось бы, если бы я мог как-то сделать:

<javadoc suppressWarrnings="true"

или что-то подобное, чтобы компилятор javadoc не выводил все предупреждающие сообщения. Возможно ли подобное (глобальное предупреждение о отключении javadoc)?

ОТВЕТЫ

Ответ 1

И задача ant, и сам инструмент javadoc не могут отключать предупреждения глобально.

Одним из возможных решений, о которых я могу думать, является запуск javadoc-задачи в виде отдельного вызова ant из остальной части сборки. Вы можете использовать аргумент -logfile для ant, чтобы перенаправить вывод в файл журнала, а не на консоль.

Ответ 2

В Java 8 вы можете добавить additionalparam="-Xdoclint:none" в задачу javadoc. (Источник)

Ответ 3

Попробуйте флаг -quiet.

Ответ 4

Ответ на ответ звучит хорошо для меня и, вероятно, будет отлично работать для тех, кто не использует систему непрерывной сборки Cruise Control. Тем не менее, я обнаружил, что для тех, кто (как я) использует эту систему, существует другой способ.

Круиз-контроль собирает свои отчеты, используя несколько таблиц стилей XSLT. В нашем случае эти таблицы стилей находились в:

~/applications/cruisecontrol-bin-2.7.3/webapps/cruisecontrol/xsl

но поскольку я не устанавливал нашу установку, я не знаю, является ли это стандартным путем или нет. Несмотря на это, вы должны иметь возможность найти эквивалентный каталог в своей установке. Внутри этого каталога находится файл с именем errors.xsl. Чтобы избавиться от предупреждений, вам нужно внести два изменения в этот файл, оба из которых включают в себя комментирование существующих правил.

Заменить:

<xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/>

с:

<!--        <xsl:variable name="total.errorMessage.count" select="count($warn.messages) + count($error.messages)"/>-->
<xsl:variable name="total.errorMessage.count" select="count($error.messages)"/>

Это приведет к тому, что "количество ошибок" будет подсчетом фактических ошибок, а не количеством ошибок + предупреждений.

Затем замените:

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

с:

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

Это скроет сами предупреждения. В качестве альтернативы вы всегда можете просто удалить прокомментированный код, но тогда вы должны сначала создать резервную копию файла, если вы когда-нибудь захотите вернуть свои предупреждения. Кроме того, XSLT игнорирует любую разметку, отличную от XSLT, поэтому вы можете делать другие вещи с предупреждениями, кроме как полностью исключая их: например, вы можете обернуть все предупреждения в DIV, а затем использовать CSS/Javascript для "обрушения" предупреждений вместо того, чтобы полностью их удалять.

Хотя мне в конечном итоге пришлось самому найти это решение, все ответы здесь помогли мне понять, что происходит, поэтому спасибо за помощь.

Ответ 5

В настоящее время некоторые нестандартные параметры javadoc позволяют избежать чрезмерного количества ошибок и/или предупреждений. Проверьте javadoc help (выполните javadoc -X); должны быть доступны следующие нестандартные параметры:

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

-Xmaxerrs задает максимальное количество ошибок для печати -Xmaxwarns устанавливает максимальное количество предупреждений для печати -Xdoclint включает или отключает определенные проверки проблем в комментариях javadoc.

Например, указание -Xdoclint:none отключит определенные проверки большинства проблем в комментариях javadoc; и -Xmaxwarns 1 ограничит количество предупреждений на 1 (я попробовал -Xmaxwarns 0, но затем он напечатал все предупреждения, поэтому я предполагаю, что 0 означает отсутствие ограничений)

Ответ 6

Я только что обнаружил, что был немного лучший вариант того, что я описал в своем предыдущем ответе. Вместо редактирования 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"

Если вы следуете этому совету комментариев (закомментируйте две строки, которые он упоминает и раскомментирует одну строку, о которых он упоминает), вы получаете тот же точный эффект, но с включенными ошибками компиляции.

Зачем беспокоиться об этом методе по сравнению с предыдущим? Ну, я думаю (я действительно должен был проверить это лучше, но я ленился), что мой предыдущий метод ест ошибки компиляции; этот метод сохраняет их.