Maven 构建应该只是使用Checkstyle之类的方式报告格式错误，而不是自动格式化代码。你的描述似乎就是这个意思。这样，错误会在构建时报告给开发人员/Hudson，并且可以根据需要解决。
我还建议使用像Sonar这样的工具来保留格式错误的历史记录（请参阅他们的时间机器功能）。
为了使您的项目格式一致，您需要配置工具以自动执行此操作。我建议如下：
Eclipse 格式化程序
对于 Eclipse，Preferences (Java->Code Style->Formatter) 中有一个选项，您可以在其中配置您希望如何格式化项目。创建一个新的配置文件并将您的配置放在那里。
完成后，有一个导出功能（它隐藏得很好，单击编辑然后导出）。将配置传递给团队的其他成员，以便他们可以导入它。
Eclipse 保存操作
仍然配置格式化程序并不能保证开发人员会在提交之前格式化代码，因此您需要配置自动格式化。
再次转到首选项（Java->Editor->Save Actions）并选择格式化源代码。这样代码在保存文件时被格式化。
Eclipse Checkstyle 插件
一些开发人员可能会忘记正确执行这些步骤，因此您需要一种方法来定位它。
为 Eclipse 安装 Checkstyle 插件：
安装插件后，您可以为其创建配置。然后可以为团队的其他成员导出配置，或者甚至更好地上传到服务器并远程引用配置。
远程配置的优点是您还可以通过 maven-checkstyle-plugin 引用它，它可以通过在 CI 服务器上启动它来为您提供报告。
如果您想成为硬核，您可以将基本配置（由格式化程序自动完成的配置）设置为错误而不是警告，以便具有错误配置 eclipse 的开发人员在提交之前看到错误。
预配置的 Eclipse
如果您想更上一层楼，您可以创建一个预配置的 eclipse，并将该版本分发给您的开发人员，这样他们就不需要做任何事情。
副作用奖励：您可以避免开发平台上的版本不一致。配置管理不仅涉及源代码，还涉及开发工具。使事情更加可预测。
处理此问题的一种方法是使用Jalopy或JIndent甚至 Eclipse 内置代码格式化程序（您可以从命令行调用）在预提交挂钩中格式化代码。AFAIK，如果您不能强制人们在提交之前运行自动构建，这是确保版本化代码始终正确格式化的唯一方法。但我不知道 Perforce 是否支持预提交挂钩。
如果没有，另一种选择是在构建时使用Jalopy Maven 插件或Maven Checkstyle 插件，并在规则被破坏时使构建失败（并让 CI 引擎报告它）。不过，化妆品的构建失败可能会很烦人。
因此，确实，运行一个夜间进程来格式化代码可能是一种替代方法。在这种情况下，Jalopy Maven 插件或其他提到的工具可能会对您有所帮助，这实际上取决于您是否要使用 Maven 来完成这项工作。
如果您的所有（或大多数）开发人员都在使用 Eclipse，您可以导出格式化规则并根据您的团队的喜好保存操作，并让每个人共享相同的偏好。
我见过的最好的解决方案是CXF采用的方法，在Connecting Maven, Eclipse, Checkstyle, and PMD中有详细描述。
他们使用另一个回复中提到的 Eclipse-cs 插件 Dimitris将 checkstyle 与Eclipse集成。这允许 Eclipse 在其代码违反任何代码格式规则时生成错误。他们还将 checkstyle 与Maven集成，因此如果他们的代码不遵守 checkstyle 规则，验证步骤将失败。它们还在 Eclipse 中定义了一组冗余的自动格式化规则，这使得快速格式化将通过 checkstyle 标准的代码变得容易。
这意味着 Eclipse 需要进行大量配置。他们通过将一组 Maven 插件组合在一起来自动执行此步骤，这些插件将生成一个特定于 CXF 的工作区，其中包括必要的 checkstyle/autoformatting 配置。
您可以在 Perforce 中设置签入规则来格式化签入代码吗？我没有使用过 perforce，所以我无法发表评论 - 但当我们在团队中讨论代码格式化强制选项时，我们认为这是合适的。
这可能没有多大帮助，但是Go 语言源代码树会使用他们设置的命令行应用程序自动格式化您推送到其中的内容。它是在 Mercurial 中完成的，而不是 Perforce。但是，也许你可以看到他们是如何做到的。详细信息必须在golang.org中的某个位置。
如果正确的格式化对你来说很重要，那么配置 Perforce 在签入时运行自己的格式化，并告诉它在源文件的格式化版本与提交的版本不同时拒绝提交。
就个人而言，我们只是使用 Eclipse Save Actions，并在保存时告诉它重新格式化。对我们来说已经足够好了。