我一直在使用wsimport工具从WSDL文件生成客户端类。然后我将它们包含在项目的源代码树中，并将它们检入版本控制系统。但最近我了解到有一个名为jaxws-maven-plugin的maven插件可以生成客户端类作为构建步骤（mvn clean jaxws：wsimport）。
虽然我不清楚使用此插件的真正好处是什么，除了不需要将WS客户端类检查到源代码控制中。仍然如果有人想要在项目上工作，他必须检查代码，然后运行mvn jaxws：wsimport然后才能开始工作（否则IDE将显示错误）。那么真正的好处是什么？何时应该使用插件而不是将客户端代码签入VCS？
答案 0 :(得分：4)
maven插件的执行可以在构建步骤中自动触发，例如，在编译项目之前，maven构建周期中专门有一个“生成源”阶段。因此，开发人员不必记住手动生成它，使您更接近理想的一键完整版本。
优点是，您可以从VCS中排除生成的类，因为它们可以按需重新生成。 VCS中生成的代码的问题是，WSDL文件中的更改将触发生成的代码中的更改（显然）。但是，当您首先处理合同时，只有WSDL文件中的更改才是相关的。从VCS中排除生成的代码将隐藏VCS提交日志中的冗余更改。您的VCS存储库较小，提交日志更清晰。
针对评论进行编辑： Imho对这种情况有两种截然不同的看法：
1）客户端类与服务接口的兼容性。
我不确定，如果客户端类能够与WS通信，如果它们是从较旧的wsdl生成的。如果更改仅限于其他方法并且未触及现有定义，我认为可能有效。尽管如此，如果始终在构建上重新生成客户端代码，则这不是问题，因为客户端代码会自动与wsdl同步。
2）实现与客户端类的兼容性。
如果生成的客户端类由于修改后的wsdl而发生更改，则可能会破坏使用客户端类的代码。但是，如果只有方法添加到wsdl并且现有方法保持不变，则重新生成的客户端类应因此向后兼容现有代码。在您的示例中：如果您的代码仅使用A（），而“新”客户端类现在向A（）提供B（） ，则您的代码仍然可以正常工作。
总结;从VCS中排除生成的客户端代码，而不是作为构建过程的一部分按需生成它应该在我看来不会破坏现有的功能代码，如果WSDL演进向后兼容的话。如果WSDL更改不向后兼容，则在编译时将发生错误。但这些是不可避免的 - 使用VCS过时的客户端类实际上可能会隐藏这些错误，直到您尝试执行该应用程序。