Как я могу подавить предупреждения (кодовые базы) во время компиляции 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"
Если вы следуете этому совету комментариев (закомментируйте две строки, которые он упоминает и раскомментирует одну строку, о которых он упоминает), вы получаете тот же точный эффект, но с включенными ошибками компиляции.
Зачем беспокоиться об этом методе по сравнению с предыдущим? Ну, я думаю (я действительно должен был проверить это лучше, но я ленился), что мой предыдущий метод ест ошибки компиляции; этот метод сохраняет их.