我被要求查看现有基于服务的应用程序的构建过程。它有几个基于服务的模块，其中一些服务由第三方提供。构建过程中使用的 wsdls 通过 http 下载并进入构建。为了竞争力，我使用 maven 3 和 axistools-maven-plugin 从 wsdl 生成类。
这让我开始思考。如果远程服务器关闭，我的构建将失败。如果 wsdl 更改我的构建也可能失败。我想要这个吗？远程 wsdl 在 service/wsdl 名称中进行了版本控制，因此不应对 API 进行重大更改，但它们是第 3 方，我不能真正依赖此约定。
在本地下载 wsdl 并针对受源代码控制的文件进行构建不是更好吗？然后我将有一个适当的可重复构建，而不会有远程服务器不可用的危险。不过，这似乎不是很敏捷。如果我采用这种方法，那么我如何知道远程 wsdl 中的任何变化？
我确信我不是第一个想知道从 wsdls 构建的最佳实践的人。任何人都可以强调什么机制被认为是从远程 wsdls 生成的服务生成可重复构建的最佳实践方式？
如果你想要快速可靠的构建，那么黄金法则就是不要依赖任何你无法控制的东西！
在您的情况下，我将在本地缓存 WSDL，以便在原始源不可用或更改时构建不会失败。但是，如果您完全担心 WSDL 可能会更改，那么我还将创建一个单独的构建作业，该作业每天运行并将缓存的副本与原始副本进行比较，如果它们不同，则会失败。这为您提供了两全其美的优势......如果 WSDL 发生变化，可重复构建和早期警告。
您在哪里/如何缓存 WSDL 完全取决于您，但将其保留在版本控制中是一个快速而简单的选择。
我会下载 WSDL 文件并将它们与项目的其余部分一起放入源代码控制中。
主要优点是它保证了可重复的构建。如果您在每个版本上下载它们，则它是不可重复的。例如，假设您构建并部署到开发或测试环境，让应用程序签名，然后构建并部署到现场。如果 WSDL 已更改，那么您的实时构建与测试中签署的不同，并且工作方式可能会有所不同。如果您有网络通信问题，那么您甚至可能根本无法构建。
这意味着您不会自动获得最新版本的 WSDL，但这是一件好事。
如果您知道 Web 服务有一个固定的 wsdl，最好使用它的本地副本。
如果 wsdl 本身可能发生变化，最好始终使用 url 进行构建。
如果网络中断是一个问题，请制作两个单独的构建配置文件（在 Maven 中），一个用于本地，另一个用于 url。