Wie kann ich während der Javadoc-Kompilierung Warnungen unterdrücken (codebase-weit)?

Question

Ich bin mit einer alten Java Codebase, die Tausende von Warnungen hat, wenn Sie es kompilieren stecken. Ich würde gerne die Quelle all dieser Warnungen korrigieren, aber leider ist das zu diesem Zeitpunkt in meinem Unternehmen keine Option (andere Dinge wie "neue Produkte, die Einnahmen generieren" werden von den Verantwortlichen als höhere Priorität angesehen). .

Jetzt könnte ich einfach mit all diesen Warnungen leben, wenn es nicht für die Tatsache, dass sie es schwierig machen würde, tatsächliche Fehler in der Ausgabe von unserem Continuous Build Server zu finden. Der Build-Server verwendet nur einen Ant-Aufruf, nichts Schickes, aber bisher konnte ich nirgendwo etwas finden, wie ich diesen Aufruf ändern könnte, um eine Warnung zu vermeiden.

Das Durchgehen des Codes und das Hinzufügen einer @SuppressWarnings-Annotation würde überall funktionieren, aber es wäre auch fast so schmerzhaft, als würde man alle Quellen der Warnungen durchgehen und reparieren. Also, was ich wirklich liebe, ist, wenn es nur irgendwie war ich tun konnte:

<javadoc suppressWarrnings="true" 

oder etwas ähnliches, um die javadoc Compiler zu machen nicht ausgegeben alle Warnmeldungen. Ist so etwas möglich (globale Javadoc-Warnung deaktiviert)?

Answer 1

Sowohl das ant-Task- als auch das javadoc-Tool selbst haben keine Möglichkeit, Warnungen global zu deaktivieren.

Eine mögliche Problemumgehung, die ich mir vorstellen kann, besteht darin, den Javadoc-Task als einen separaten Ant-Aufruf vom Rest des Builds auszuführen. Sie können das Argument -logfile verwenden, um die Ausgabe in eine Protokolldatei und nicht in die Konsole umzuleiten.

Answer 2

Versuchen Sie die -quiet Flagge.

Answer 3

Marks Antwort klingt gut für mich und würde wahrscheinlich gut für jeden funktionieren, der das Cruise Control Continuous Build System nicht verwendet. Ich entdeckte jedoch, dass es für jeden, der (wie ich) dieses System benutzt, einen anderen Weg gibt.

Cruise Control stellt seine Berichte mithilfe mehrerer XSLT-Stylesheets zusammen. In unserem Fall residiert diese Sheets in:

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

aber da ich nicht Setup unsere Installation haben, weiß ich nicht, ob das ein Standard-Pfad ist oder nicht. Unabhängig davon sollten Sie in der Lage sein, ein entsprechendes Verzeichnis in Ihrer Installation zu finden. In diesem Verzeichnis befindet sich eine Datei namens errors.xsl. Um die Warnungen loszuwerden, müssen Sie zwei Änderungen an dieser Datei vornehmen, bei denen Sie die vorhandenen Regeln auskommentieren müssen.

ersetzen:

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

mit:

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

Dies wird der „Fehlerzähler“ werden, um eine Zählung der tatsächlichen Fehler, anstatt eine Zählung der Fehler + Warnungen machen.

Dann ersetzen:

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

mit:

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

Dies wird den tatsächlichen Warnungen sich verstecken.Alternativ können Sie den auskommentierten Code immer löschen, aber dann sollten Sie die Datei zuerst sichern, für den Fall, dass Sie Ihre Warnungen jemals wieder erhalten möchten. Außerdem ignoriert XSLT alle Nicht-XSLT-Markups, sodass Sie andere Dinge mit den Warnungen tun können, als sie vollständig zu eliminieren: Sie könnten beispielsweise alle Warnungen in ein DIV umbrechen und anschließend CSS/Javascript verwenden, um die Warnungen "zu reduzieren" anstatt sie vollständig zu entfernen.

Obwohl ich diese Lösung letztendlich selbst herausfinden musste, haben mir alle Antworten geholfen, zu verstehen, was vor sich ging, also vielen Dank für die Hilfe.

Answer 4

Ich entdeckte gerade, dass es eine etwas bessere Variante von dem gab, was ich in meiner vorherigen Antwort beschrieben habe. Bearbeiten Sie buildresults.xsl statt editing.xsl. Diese Datei enthält einen Kommentar:

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

Wenn Sie diesen Kommentar Rat folgen (kommentieren Sie die beiden Linien es erwähnt und Kommentar- der eine Zeile es erwähnt) Sie genau die gleiche Wirkung, aber mit Kompilierungsfehlern enthalten.

Warum mit dieser Methode im Vergleich zu meiner vorherigen? Nun, ich denke (ich hätte das besser testen sollen, aber ich bin faul geworden), dass meine vorherige Methode Kompilierungsfehler verursacht; Diese Methode bewahrt sie.

Answer 5

In Java 8 können Sie additionalparam="-Xdoclint:none" zur javadoc Aufgabe hinzufügen. (Source)

Answer 6

Heutzutage können Sie mit einigen Javadoc-Nichtstandardoptionen eine übermäßige Anzahl von Fehlern und/oder Warnungen vermeiden. Überprüfen Sie die Hilfe von Javadoc (führen Sie javadoc -X aus); die folgenden Nicht-Standard-Optionen sollten zur Verfügung stehen:

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

-Xmaxerrs die maximale Anzahl von Fehlern setzen -Xmaxwarns legt die maximale Anzahl von Warnungen drucken spezifische Prüfungen für Probleme in javadoc Kommentaren -Xdoclint aktiviert oder deaktiviert zu drucken.

Wenn Sie beispielsweise -Xdoclint:none angeben, werden bestimmte Prüfungen für die meisten Probleme in Javadoc-Kommentaren deaktiviert. und -Xmaxwarns 1 wird die Anzahl der Warnungen auf 1 beschränken (Ich habe versucht -Xmaxwarns 0, aber dann druckte es alle Warnungen, so meine Vermutung ist 0 bedeutet keine Grenze)