当我尝试使用菜单命令Project \ Generate Javadoc生成javadoc时，会在XPage中为我的自定义类生成以下警告和错误：
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和Custom Control类生成Javadoc。
答案 0 :(得分：1)
您遇到此行为，因为javadoc无法理解Designer VFS（虚拟文件系统）。它假设您的项目由本地硬盘驱动器上的某些文件夹结构中的一组单独文件组成，而不是单个NSF中的自包含文件。总的来说，Designer VFS成功地让Eclipse相信它通过拦截对项目资源的读/写请求以及导入/导出DXL或CD记录等来与本地文件进行交互。但显然他们没有将这种手段应用于javadoc同样。
与每个XPage和Custom Control对应的Java源文件都已成功处理，因为具有讽刺意味的是，它们永远不会存储在NSF中。在每个项目构建期间，Designer会丢弃已生成的任何项目，并根据各种.xsp文件的当前内容重新创建它们。然后，它将这些Java文件编译为.class文件，其中 存储为NSF内的设计注释。在运行时，这些文件是从VFS中提取并执行的...此时源代码不再重要，因此没有理由在NSF中包含.java文件，所以它们只是保持在硬盘。此行为的一个指示是，在Package Explorer / Navigator中查看时，该文件夹名为“Local”。
如果您正在使用内置（从8.5.3开始）版本控制集成（请参阅this article以获得有关如何使用此功能的详细说明），您可以调整构建路径以包含副本存储在磁盘项目中的src文件夹的“链接源文件夹”。这会导致javadoc考虑重复副本的有效源文件，因此将它们包含在生成的文档中。在缺点方面，它还会导致Designer将它们视为有效的源文件，这会因复制而导致编译错误。因此，如果您只需要不经常生成文档，这种方法是可行的，因此可以暂时中断构建路径以运行javadoc，然后恢复到通常的设置。
另一种方法是以持续的方式实际维护自定义Java代码：不是在NSF内的WEB-INF中创建文件夹，只需在硬盘上创建一个存储源的文件夹，然后包含该位置无限期地作为链接的源文件夹。这样设计师仍然可以找到源，但javadoc也是如此。 注意：如果你走这条路，你肯定需要使用SCM。因为您的源代码不再存在于NSF内部，所以提供了方便的容器，我们习惯于将源代码提供给其他开发人员并确保包含在您使用的任何备份计划中， only 现在将源代码放在本地硬盘上。因此，请确保您经常将这些文件提交给Git / Subversion / Mercurial等，或者至少将它们存储在定期备份的文件服务器上，如果适用，可以访问所有其他成员。项目团队。
答案 1 :(得分：0)
在Designer中展开net.focul.utilties时，您将看到所有方法和属性。但是当你点击方法时，你会看到新的源代码。 所以这就是javadoc无法生成文档的地方。我猜应用程序的作者没有为您提供源代码。如果您在某处拥有源代码，则可以附加此代码，然后javadoc将能够生成文档。
答案 2 :(得分：0)
我遇到了同样的情况，我发现最简单的方法是将源导出到外部文件夹，然后使用常规Eclipse生成JavaDoc。不确定我的过程是否比蒂姆的建议更麻烦，但对我来说，它只是觉得风险小于试图处理VFS变幻莫测的风险。