JAXWS：为什么要通过jaxws-maven-plugin在maven中生成客户端代码？

Question

我总是使用wsimport工具从WSDL文件生成客户端类。然后我将它们包含到一个项目的源代码树中，并将它们检入到版本控制系统中。但最近我了解到，有一个名为jaxws-maven-plugin的插件可以生成客户端类作为构建步骤（mvn clean jaxws：wsimport）。

虽然我不清楚使用这个插件的真正好处是什么，除了不需要检查WS客户端类到源代码控制。如果有人想要在项目上工作，他必须检查代码，然后运行mvn jaxws：wsimport，然后才能开始工作（否则IDE将显示错误）。那么真正的好处是什么？何时应该使用插件而不是将客户端代码签入VCS？

Answer 1

可以在构建步骤中自动触发Maven插件的执行，例如，在编译该项目之前，在Maven构建周期中专门设置了“生成源代码”阶段。因此，开发人员不必记住手动生成它，使您更接近理想的单击完整构建。

优点是，您可以从VCS中排除生成的类，因为它们可以根据需要重新生成。 VCS中生成的代码的问题在于，WSDL文件中的更改会触发生成的代码中的更改（显然）。但是，当您首先处理合同时，只有WSDL文件中的更改才是相关的。从VCS中排除生成的代码将隐藏VCS提交日志中的冗余更改。您的VCS存储库较小，提交日志更清晰。

编辑旨在评论： 恕我直言有对场景两种截然不同的观点：

1）服务接口的客户端类的兼容性。

我不确定，如果客户端类能够与WS通信，如果它们是从较旧的wsdl生成的。我认为它可能工作，如果更改仅限于其他方法，并不触及现有的定义。尽管如此，如果客户端代码总是在构建版本上重新生成，这是一个非问题，因为客户端代码自动与wsdl同步。

2）实现与客户端类的兼容性。

如果生成的客户端类由于修改的wsdl而发生更改，则可能会破坏使用客户端类的代码。但是，如果只有方法添加到wsdl并且现有方法保持原样，那么重新生成的客户端类应该与现有代码向后兼容。在你的例子中：如果你的代码只使用A（），并且“新”客户类现在向A（）提供B（）另外，你的代码仍然可以工作。

总之;不包括从VCS生成的客户端代码，而是根据需要生成它作为构建过程的一部分，在我看来，如果WSDL演进向后兼容，应该不会破坏现有的功能代码。如果WSDL更改不向后兼容，则编译时会发生错误。但这些都是不可避免的 - 使用来自VCS的过时客户端类可能会实际上隐藏这些错误，直到您尝试执行该应用程序。