如何从 javadoc Ant 任务的结果中排除特定的方法/构造函数？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1120455/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I exclude a specific method/constructor from the results of the javadoc Ant task?
提问by Kevin Wong
I'm using javadocs generated by the javadocAnt task to document a web service, and I want to exclude some constructors from the output. How do I do that?
我正在使用javadocAnt 任务生成的 javadoc来记录 Web 服务，并且我想从输出中排除一些构造函数。我怎么做？
回答by Brian Agnew
See the relevant Javadoc FAQ entry.
请参阅相关的Javadoc FAQ 条目。
There is currently no Javadoc option to hide, exclude or suppress public members from the javadoc-generated documentation.
当前没有 Javadoc 选项可以从 javadoc 生成的文档中隐藏、排除或禁止公共成员。
It would appear this is not possible in the vanillaJavadoc, but some workarounds are offered.
看起来这在vanillaJavadoc 中是不可能的，但提供了一些解决方法。
回答by Kevin Wong
Change the method access level of the method, then use the use the javadoctask's access-level filtering attributes, private, package, etc. Only do this if it makes sense in your code, though, e.g., method that had inappropriately loose access levels.
更改方法的方法访问级别，然后使用javadoc任务的访问级别过滤属性private、package、 等。仅当它在您的代码中有意义时才执行此操作，例如，具有不适当松散访问级别的方法。
For constructors, for example, you could reduce the access level to package, then create a factory class in the same package that provides construction access outside the package. The factory class can be easily filtered from the javadocs. Kind of hacky, but it works.
例如，对于构造函数，您可以将访问级别降低到package，然后在同一个包中创建一个工厂类，提供包外的构造访问。工厂类可以很容易地从 javadoc 中过滤出来。有点hacky，但它有效。
回答by Uri
There is no way to do this for public methods. The standard practice (even in quite a few JDK classes) is to indicate that the method or constructor is not meant for public use.
对于公共方法，没有办法做到这一点。标准做法（即使在相当多的 JDK 类中）是表明该方法或构造函数不供公共使用。
There is a plan to add an @exclude tag in the future:
@exclude - for API to be excluded from generation by Javadoc. Programmer would mark a class, interface, constructor, method or field with @exclude. Presence of tag would cause API to be excluded from the generated documentation. Text following tag could explain reason for exclusion, but would be ignored by Javadoc. (Formerly proposed as @hide, but the term "hide" is more appropriate for run-time dynamic show/hide capability.) For more discussion, see: Feature Request #4058216in Developer Connection.
@exclude - 用于从 Javadoc 生成中排除的 API。程序员会用@exclude 标记一个类、接口、构造函数、方法或字段。标签的存在会导致 API 从生成的文档中排除。标签后面的文本可以解释排除的原因，但会被 Javadoc 忽略。（以前提议为@hide，但术语“隐藏”更适合运行时动态显示/隐藏功能。）有关更多讨论，请参阅： Developer Connection 中的功能请求 #4058216。
回答by Szemere
Give Chris Nokleberg's ExcludeDoclet a try: http://www.sixlegs.com/blog/java/exclude-javadoc-tag.html
试试 Chris Nokleberg 的 ExcludeDoclet：http: //www.sixlegs.com/blog/java/exclude-javadoc-tag.html
I've just been experimenting with it and it seems to do the trick.
我刚刚在试验它，它似乎奏效了。
回答by Rob Hruska
Isn't excluding something public from your documentation just a variation on "security through obscurity" (or rather, "documentation through obscurity")? If the constructor is part of your code's API, it's available for them to use. If they find out about it and use it, is that their fault (since you made it public in the first place)?
从您的文档中排除一些公开的内容是否只是“通过默默无闻的安全性”（或者更确切地说，“通过默默无闻的文档”）的变体？如果构造函数是代码 API 的一部分，则可供他们使用。如果他们发现并使用它，那是他们的错（因为你首先公开了它）？
If you can change the constructor's visibility or remove it altogether, I would go for that. If you cannot remove it from the API, make it known in the Javadoc for the constructor that it's not intended for use via web service. That way you've established a contract with users of your API, informing them not to use it.
如果您可以更改构造函数的可见性或将其完全删除，我会这样做。如果您无法从 API 中删除它，请在构造函数的 Javadoc 中说明它不打算通过 Web 服务使用。这样您就与 API 的用户签订了合同，通知他们不要使用它。
It's better to document that it should not be used instead of not documenting it at all (if it's public). Not documenting it adds risk that it gets inadvertently used, and then the client code using it breaks when you change the implementation.
最好记录它不应该使用而不是根本不记录它（如果它是公开的）。不记录它会增加无意中使用它的风险，然后当您更改实现时，使用它的客户端代码会中断。
回答by mhsmith
Currently the simplest solution is to start the javadoc comment with @deprecated, and then pass -nodeprecatedto the javadoccommand. Of course, this may not be acceptable if you have actual deprecated items which you nevertheless want to include in the documentation.
目前最简单的解决方案是用 开始javadoc 注释@deprecated，然后传递-nodeprecated给javadoc命令。当然，如果您有实际已弃用的项目，但您仍希望将其包含在文档中，则这可能是不可接受的。
