2009-03-06 3 views
10

Je suis coincé avec une base de code Java héritée qui a des milliers d'avertissements lorsque vous le compilez. J'aimerais vraiment régler la source de tous ces avertissements, mais malheureusement, ce n'est pas une option pour le moment dans mon entreprise (d'autres choses comme «fabriquer de nouveaux produits générateurs de revenus» sont considérées comme prioritaires par les responsables; .Comment puis-je supprimer les avertissements (à l'échelle de la base de code) pendant la compilation de javadoc?

Maintenant, je pourrais vivre avec tous ces avertissements, si ce n'était pas pour le fait qu'ils rendent difficile de trouver des erreurs réelles dans la sortie de notre serveur de construction continue. Le serveur de construction utilise simplement un appel de fourmi, rien d'extraordinaire, mais jusqu'à présent, je n'ai trouvé nulle part comment modifier cet appel pour empêcher la sortie d'avertissement.

En passant par le code et en ajoutant une annotation partout @SuppressWarnings fonctionnerait, mais il serait aussi presque autant d'une douleur en passant par la fixation et toutes les sources les avertissements. Donc ce que j'aimerais vraiment est de savoir s'il y avait juste une certaine façon que je pouvais faire:

<javadoc suppressWarrnings="true" 

ou quelque chose de similaire, pour faire le compilateur javadoc pas émis tous les messages d'avertissement. Est-ce que quelque chose comme ceci (avertissement global de javadoc désactivant) possible?

Répondre

5

La tâche ant et l'outil javadoc lui-même n'ont aucun moyen de désactiver les avertissements globalement.

Une solution de contournement possible que je peux penser est d'exécuter la tâche javadoc comme un appel de fourmi distinct du reste de la construction. Vous pouvez utiliser l'argument -logfile dans ant pour rediriger la sortie vers un fichier journal plutôt que vers la console.

6

Essayez le drapeau -quiet.

+0

Question stupide: savez-vous comment passer ce drapeau dans fourmi? – machineghost

+0

Je pense avec additionalparam – anon

+0

Essayez comme ceci: < javadoc // autres éléments additionalparam = « quiet » /> – anon

1

La réponse de Mark me semble bonne, et fonctionnerait probablement bien pour quiconque n'utilisant pas le système de construction continue Cruise Control. Cependant, j'ai découvert que pour quiconque (comme moi) utilise ce système, il y a un autre moyen. Le régulateur de vitesse assemble ses rapports en utilisant plusieurs feuilles de style XSLT.

Dans notre cas, ces feuilles de style résidaient dans:

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

mais comme je ne l'ai pas configuré notre installation, je ne sais pas si c'est un chemin d'accès standard ou non. Peu importe, vous devriez pouvoir trouver un répertoire équivalent dans votre installation. À l'intérieur de ce répertoire se trouve un fichier appelé errors.xsl. Pour vous débarrasser des avertissements, vous devrez apporter deux modifications à ce fichier, qui impliquent toutes les deux de commenter les règles existantes.

Remplacer:

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

avec:

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

Cela rendra le « nombre d'erreurs » soit un décompte des erreurs réelles, au lieu d'un nombre des erreurs + avertissements.

Ensuite, remettre en place:

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

avec:

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

Cela permet de masquer les avertissements réels eux-mêmes.Alternativement, vous pouvez toujours simplement supprimer le code commenté, mais vous devriez vraiment sauvegarder le fichier en premier, au cas où vous voudriez récupérer vos avertissements. De plus, XSLT ignore tout balisage non-XSLT, donc vous pouvez faire d'autres choses avec les avertissements en plus de les éliminer complètement: par exemple, vous pouvez envelopper tous les avertissements dans un DIV, puis utiliser CSS/Javascript pour "réduire" les avertissements. au lieu de les enlever entièrement.

Bien que je devais finalement découvrir moi-même cette solution, toutes les réponses ici m'a aidé à comprendre ce qui se passait, donc merci à tous pour l'aide.

0

Je viens de découvrir qu'il y avait une variante légèrement meilleure de ce que j'ai décrit dans ma réponse précédente. Au lieu d'éditer errors.xsl, éditez buildresults.xsl. Ce fichier contient un commentaire:

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

Si vous suivez que les conseils de commentaire (commenter les deux lignes qu'il mentionne et décommenter une ligne, il mentionne), vous obtenez exactement le même effet, mais avec des erreurs de compilation inclus. Pourquoi s'embêter avec cette méthode par rapport à la précédente? Eh bien, je pense (j'aurais vraiment dû tester cela mieux, mais je suis paresseux) que ma méthode précédente mange des erreurs de compilation; cette méthode les préserve.

8

En Java 8, vous pouvez ajouter à la tâche additionalparam="-Xdoclint:none"javadoc. (Source)

+0

Je vois encore des avertissements quand je fais cela, mais c'est bien mieux que de voir 99 avertissements que je n'ai pas le temps de réparer. –

1

Aujourd'hui quelques javadoc options non standard vous permettent d'éviter un trop grand nombre d'erreurs et/ou des avertissements. Vérifiez l'aide de javadoc (exécutez javadoc -X); les options suivantes doivent être non standard disponibles:

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

-Xmaxerrs fixe le nombre maximum d'erreurs pour imprimer -Xmaxwarns définit le nombre maximal d'avertissements pour imprimer -Xdoclint active ou désactive des contrôles spécifiques pour les problèmes dans les commentaires javadoc.

Par exemple, en spécifiant -Xdoclint:none désactive les contrôles spécifiques pour la plupart des problèmes dans les commentaires javadoc; et -Xmaxwarns 1 limitera le nombre d'avertissements à 1 (j'ai essayé -Xmaxwarns 0, mais alors il a imprimé tous les avertissements, donc je suppose que 0 signifie aucune limite)

Questions connexes