J'ai googling pendant presque une heure et je ne trouve aucune bonne information sur la création de balises personnalisées. Lorsque je vérifie l'aide pour Javadoc, il s'agit de cela sur les balises personnalisées ...
-tag Cela ne définit pas ce que sont les choses. Je pense que le nom serait le nom de la balise et de l'en-tête est probablement ce que dit la balise lorsque vous générez le Javadoc mais quels sont les emplacements et comment est-il utilisé?
Le nom, les emplacements et l'en-tête doivent également être entre citations ou quoi que ce soit comme ça?
Quelques exemples de balises personnalisées et peut-être une explication de quels endroits seraient une aide énorme pour moi. Je ne trouve aucun bons tutoriels sur cette partie spécifique de la fabrication de Javadoc ...
3 Réponses :
Vous avez uniquement appelé En principe, tout est expliqué en détail sur la page de documentation Javadoc (pour Windows et Linux / Solaris ). P> Le donc, si vous javadoc -help code>. Ceci n'est qu'un court rappel sur les options, pas une documentation complète. -tag code> option est destiné à ajouter des balises personnalisées au doculet standard sans avoir à créer une propre tamite (vous utiliseriez le -taglet Code> Option ) ou même un propre docuté. P> Tous les paramètres à l'option doivent être un argument de ligne de commande, donc en fonction de votre coquille, vous devez généralement les mettre (ensemble ou individuellement) dans des guillemets s'ils contiennent des espaces. P>
-tag code> tagname em> : xaoptcmf: code> " taghead em>" p> " P>"
blockQuote>
@todo code> dans la source, le nom serait toDO code>. li>
a code> (partout), o code> (uniquement dans la page d'aperçu), p code> (sur la documentation de package), T code> (pour la documentation de classe ou d'interface), C code> (pour constructeurs), m code> (pour méthodes), f code> (pour des champs). De plus, il peut y avoir un x code> signifie que la balise est acceptée mais aucune sortie affichée. (Ensuite, vous n'avez pas besoin du taghead em> partie). Li>
à faire: code> pour notre tag TODO. LI>
ul> @TODO code> Tag doit être autorisé partout et imprimer à faire: code>, vous utiliseriez P> -tag todo:a:"To Do:"
Vous pouvez écrire des taglettes personnalisées et les accrocher à Javadoc relativement facilement - il existe un document expliquant comment ici . Notez que vous devez spécifier le chemin absolu complet à l'emplacement du taglet, mais cela peut être fait relativement facilement dans la fourmi.
Taglets prend plus de temps que d'utiliser la commande TAG, mais ils offrent une grande plus grande flexibilité car vous exécutez essentiellement quel que soit le code Java que vous choisissez - de cette façon, vous pouvez traiter ou afficher toutes les informations que vous le souhaitez.
Paŭlo Ebermann est correct, mais j'aimerais ajouter que Oracle a déclaré:
éviter les conflits - Si vous voulez couper votre propre espace de noms, vous peut utiliser une convention de dénomination séparée par points similaire à celle utilisée pour FACKAGES: COM.MYCOMPANY.TODO. Le soleil continuera à créer de la norme Tags dont les noms ne contiennent pas de points. Toute balise que vous créez sera remplacée Le comportement d'une balise par le même nom défini par le Soleil. En d'autres termes, Si vous créez une étiquette ou un taglet @TODO, il aura toujours le même comportement que vous définissez, même si Sun plus tard crée une étiquette standard de la même nom
http://docs.oracle. COM / Javase / 1.4.2 / Docs / Tooldocs / Windows / Javadoc.html # Tag
ce qui signifie que vous ne devriez pas utiliser
@todo , vous devez utiliser@ to.doPlus d'infos ici .