Как я могу подавить предупреждения (по всей кодовой базе) во время компиляции Javadoc? - PullRequest
11 голосов
/ 07 марта 2009

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

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

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

<javadoc suppressWarrnings="true"

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

Ответы [ 6 ]

8 голосов
/ 26 марта 2015

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

6 голосов
/ 07 марта 2009

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

5 голосов
/ 07 марта 2009

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

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

2 голосов
/ 27 июня 2016

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

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

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

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

1 голос
/ 10 марта 2009

Ответ Марка звучит хорошо для меня, и, вероятно, отлично подойдет для тех, кто не использует систему непрерывной сборки 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, чтобы «свернуть» предупреждения вместо того, чтобы полностью удалить их.

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

0 голосов
/ 11 марта 2009

Я только что обнаружил, что есть немного лучший вариант того, что я описал в моем предыдущем ответе. Вместо того, чтобы редактировать ошибки. Xsl, отредактируйте buildresults.xsl. Этот файл содержит комментарий:

for traditional cc display of only compile errors and warnings
comment out mode="errors" and uncomment mode="compile" and mode="javadoc"

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

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

...