如果 JAR 文件在 Maven Central 中可用，为什么要将它们打包到 WAR 存档中？
我想知道是否可以以某种方式通知 Servlet 容器在部署期间从 Maven Central 下载所需的 JAR 存档，而不是将它们打包到 WAR 中（在 WEB-INF/lib 中）。据我了解，Java 的设计就是考虑到了这种方法。技术上可行吗？
I wonder whether it's possible somehow to inform Servlet Container to download required JAR archives from Maven Central during deployment, instead of packaging them into WAR (in WEB-INF/lib). As far as I understand Java is designed with such an approach in mind. Is it technically possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道有任何 servlet 容器可以执行此操作。 Servlet 规范规定 WAR 文件将包含应用程序的所有依赖项。当然，任何事情“技术上都是可能的”，这是一个有趣的想法，但我认为你会做很多自定义编码。我认为唯一能与之相近的是 Virgo Web Server。它是一个 OSGi/Spring DM 容器，它的概念是 一个“存储库”，可以在其中找到工件并按需加载。它可以是 配置为使用本地 Maven 存储库。如果还没有选择的话，使其使用远程存储库应该是一个相对较短的步骤。 Virgo 允许将 WAR 以及 OSGi 包部署到其中，但它不是典型的 servlet 容器。
I'm not aware of any servlet container that does this. The servlet spec says that a WAR file will contain all the dependencies for the app. Of course, anything is "technically possible", and it's an interesting idea, but I think you'd be doing a lot of custom coding. The only thing I think of that's even remotely close is Virgo Web Server. It's an OSGi/Spring DM container, and it has a concept of a "repository" where artifacts can be found and loaded on demand. It can be configured to use a local Maven repo. It should be a relatively short step to make it use a remote repo, if that isn't already an option. Virgo allows WARs to be deployed to it as well as OSGi bundles, but it isn't a typical servlet container.
Servlet 规范出现在 Maven 之前。这就是为什么 war 文件应该包含 jar 的原因。
如果你问为什么他们不改变这一点：两个原因：
如果你问这是否可能并且是个好主意。这是可能的，但这可能不是一个好主意。您应该部署已经测试过的东西（在分阶段和/或 QA 环境中）。您无法确认存储库中的依赖项不会被替换，因为您无法确定在部署期间与存储库的连接是否正常，这将破坏您的部署。
The servlet spec comes before maven. That's why the war files should contain the jars.
If you are asking why they don't change that: two reasons:
If you are asking if it is possible and a good idea. It is possible, but it may not be a good idea. You should deploy something that is already tested (on a staged and/or QA environment). You can't confirm that the dependency in the repo won't be replaced, as you can't be sure that the connectivity to the repository will be OK during deployment, which will break your deployment.