当我尝试使用菜单命令 Project\Generate Javadoc 生成 javadoc 时，会为我在 XPages 中的自定义类生成以下警告和错误：
javadoc: warning - No source files for package net.focul.utilties
javadoc: warning - No source files for package net.focul.workflow
javadoc: error - No public or protected classes found to document.
这些包位于WebContent/WEB-INF/src构建路径中配置的文件夹中，并且可以在 Generate Javadoc 向导中选择。这些类是具有公共方法的公共类。
如果我选择这些，将为所有 Xpage 和自定义控件类生成 Javadocs。
您遇到此行为是因为 javadoc 不了解 Designer VFS（虚拟文件系统）。它假定您的项目由本地硬盘驱动器上某些文件夹结构中的一堆单独文件组成，而不是在单个 NSF 中自包含。总的来说，Designer VFS 通过拦截项目资源的读/写请求和导入/导出 DXL 或 CD 记录等成功地欺骗 Eclipse，使其相信它正在与本地文件交互。但显然他们没有将这种花招应用到 javadoc也是。
与每个 XPage 和自定义控件对应的 Java 源文件都被成功处理，因为讽刺的是，它们从未存储在 NSF 中。在每个项目构建期间，Designer 都会丢弃它已经生成的任何这些文件，并根据各种 .xsp 文件的当前内容重新创建它们。然后它将这些 Java 文件编译为 .class 文件，这些文件作为设计说明存储在 NSF 中。在运行时，正是这些文件从 VFS 中提取并执行……此时源代码不再重要，因此没有理由费心在 NSF 中包含 .java 文件，因此它们只是继续存在硬盘。这种行为的一个迹象是，当在包资源管理器/导航器中查看时，该文件夹被命名为“本地”。
如果您使用的是内置（从 8.5.3 开始）版本控制集成（有关如何使用此功能的详细说明，请参阅本文），您可以调整构建路径以包含 src 文件夹的副本存储在磁盘上的项目作为“链接源文件夹”。这会导致 javadoc 认为重复的副本是有效的源文件，因此将它们包含在生成的文档中。不利的一面是，它还会导致 Designer 将它们视为有效的源文件，从而导致由于重复而导致编译错误。因此，这种方法仅在您只需要不经常生成文档时才可行，因此可以暂时中断构建路径以运行 javadoc，然后恢复到通常的设置。
另一种方法是持续以这种方式实际维护您的自定义 Java 代码：与其在 NSF 内的 WEB-INF 中创建文件夹，只需在硬盘上创建一个文件夹来存储源代码，然后将该位置包含为链接源文件夹无限期。这样，Designer 仍然可以找到源代码，但 javadoc 也可以。注意：如果你走这条路，那么你肯定需要使用 SCM。因为您的源代码不再存在于 NSF 中，所以我们提供了方便的容器，用于将源代码提供给其他开发人员并确保包含在您使用的任何备份计划中，唯一的将您的源代码现在存在于您的本地硬盘上。因此，请确保您定期将这些文件提交到 Git / Subversion / Mercurial 等，或者至少将它们存储在定期备份的文件服务器上，如果适用，所有其他成员都可以访问项目团队。
When you expand the net.focul.utilties in Designer, you will see all the methods and properties. But when you click on on of the methods, you will see neo source code. So this is where javadoc fails to generate the documentation. I guess that the author of the application has not provided you with the source code. If you have the source somewhere, you can attach this code and then javadoc will be able to generate the documentation.
我遇到了同样的情况，我发现最直接的方法是将源导出到外部文件夹，然后使用常规 Eclipse 生成 JavaDoc。不确定我的过程是否比 Tim 的建议更麻烦，但对我来说，这比尝试处理 VFS 变幻莫测的风险要小。