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

Question

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

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

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

<javadoc suppressWarrnings="true" 

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

В настоящее время некоторые нестандартные параметры 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 означает отсутствие ограничений)