在我们的商店，我们维护着大约 20 个 Java EE Web 应用程序。大多数这些应用程序的架构都非常类似于 CRUD，其中一些是非常处理器密集型的计算应用程序。
为了部署这些应用程序，我们一直在使用 Hudson 设置来监控我们的 CVS 存储库。当我们签到时，项目将被编译并部署到我们的 Tomcat 6.0 服务器(Solaris 10、sparc 双核 1.6 GHz 处理器、2 GB RAM...无论如何都不是最强大的机器想像力...) 并且，如果项目存在任何单元测试，则执行这些单元测试，并且只有在单元测试通过时才部署项目。这很好用。
现在，随着时间的推移，我发现自己创建的许多项目一遍又一遍地使用相同的 .jar 文件(Hibernate、POI(Excel 输出)、SQL Server JDBC 驱动程序、JSF、ICEFaces、业务逻辑 .jar 文件等)。我们的做法是在我们的网络驱动器上保留一个文件夹，其中存放我们一直使用的所有默认 .jar 文件，当一个新项目开始时，我们将这组 .jar 文件复制到新项目中，然后从那里开始。 ..每次发生这种情况时，我都感觉很肮脏，这让我彻夜难眠。我的同事告诉我，在 tomcat 服务器上设置一个 .jar 存储库“非常困难”，我暂时没有购买它……我将其归因于纯粹的懒惰，并且可能，不想学习最佳实践。我可能是错的，但是，我只是在陈述我对此事的感受。这似乎也增加了部署到服务器的 .war 文件的大小。
根据我的理解，Tomcat 本身有一组 .jar 文件，部署到它的所有应用程序都可以访问这些文件，所以我认为我们能够在所有项目中合并所有这些重复的 .jar 文件并移动它们到tomcat服务器上。这将只涉及更新服务器上的一个 .jar 文件，例如，如果我们需要将 ICEFaces .jar 文件更新到新版本。
我的另一部分说，通过在服务器上只包含一个 .jar 文件副本，我可能还需要在我的开发环境中保留服务器 lib 目录的副本(即在 eclipse 中包含那些 .jar 文件依赖)。
我的直觉告诉我，我想将那些重复的 .jar 文件移动到服务器上...这行得通吗？
最佳答案
我认为 Maven 和 Ivy 的诞生是为了帮助管理 JAR 依赖项。也许您会发现这些很有帮助。
至于关于在每个项目中复制 JAR 还是将它们放在服务器/库中的争论，我认为这取决于一点:您有多大可能想要升级部署在 Tomcat 上的每个应用程序同一时间？您是否曾设想过某个时间您可能有 N 个应用程序在该服务器上运行，并且第 (N+1) 个应用程序可能想要或需要特定 JAR 的更新版本？
如果您不介意保持所有应用程序同步，请务必让它们使用公共(public)库库。
就个人而言，我认为磁盘空间很便宜。我的偏好是为每个应用程序复制 JAR 并将它们放入 WAR 文件中。我喜欢分区。当 OSGi 变得更加主流时，我希望看到更多。
关于Java EE Jar 文件共享，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1051458/