java - 如何维护一组经常变化的共享库的应用程序？

Question

我有很多小型 Java 命令行应用程序，它们必须使用一组供应商的 jar 来连接到服务器，虽然编写这些应用程序非常容易，但维护它们却很困难。是。

我使用 Maven 和一些模板构建了它们，这让我在开发时间上有了相当快的周转，但到目前为止这些都是独立的命令行应用程序。

痛苦来自于供应商服务器的更新。每当发生这种情况时，它都会迫使我使用新的 jar 重新编译所有这些应用程序，否则我会遇到 SerialVersionUID 异常和崩溃的应用程序。

我正在考虑的事情

我认为可以使用 Maven 生成应用程序，然后将其放入应用程序服务器，该服务器提供一组共享供应商 .jar 在它提供的任何 /shared 类路径中。这样我就可以更新 .jars，重新启动服务器，一切都可能会继续而不会出现错误。

但是，我不确定需要什么才能使其正常工作。它们不是 .war，而且除了我的代码之外，大多数应用程序还使用其他 .jar，这些代码通常不共享。

问题

1. 什么类型的部署是这样工作的？
2. 我还缺少其他方法吗？
3. 有任何教程、框架等可以让这件事变得更简单吗？

Answer 1

我可以分享一下我的经验。目前我们有 3 种方法来克服这个问题。第一种方法是我们的​​旧方法，我们仍在使用。

1. 创建一个基础项目，我们将其与所有外部 JAR 链接到。用户项目在编译/部署时会检查基础项目是否有比当前使用的标签更新的标签，如果有更新的标签，它将失败并强制用户检查更新并重新编译。这样做的好处是，在编译时您可以检查新的 jar，我们会得到更改的列表，然后重新加载 jar。在我们的 IDE 中，我们可以快速查看 API 是否发生任何更改 - 已知会发生这种情况，然后我们可以修复并重新编译。另外，因为我们了解这些更改，所以我们可以阅读更改日志并查看是否有任何更改影响我们，然后重新测试依赖于这些库的应用程序部分。

2. 我们使用 Maven，但我们维护自己的存储库，而不是公共(public)存储库，我们仅在测试后将库移动到本地存储库 - 所以我们不会感到意外。

3. 此方法是 Tomcat 部署所独有的，但我们也使用类加载器通过 Context 加载库。这不是我最喜欢的加载外部 jar 的方式，但这种方式无需部署即可工作。当然，由于编译器无法帮助您，因此新的 jar 无法与您的代码 100% 兼容，并且您最终可能会得到一些运行时 NoSuchMethodError或ClassNotFoundException期望。