我们正在为其他内部应用程序提供一个客户端 jar，以连接到我们应用程序的 REST API。我们的 API 依赖于一些标准 Jakarta 库。将这些 JAR 文件包含在我们的客户端 jar 文件中是否是最佳实践？或者您只是记录依赖关系，并由客户端来确保他们的类路径上有这些 jar 吗？
你应该not将任何第三方 jar 作为 uber jar 捆绑到您自己的 jar 中，但最好将您的发行版中所需的所有 jar 的副本（例如 lib 目录或其他目录）包含在内。
主要原因是您的客户可能正在使用某种形式的依赖管理系统（maven/ivy 等），并且提供实际上不属于您的项目的包和类将使这些方案无效。
有一种选择，那就是使用类似Maven 阴影插件 http://maven.apache.org/plugins/maven-shade-plugin/将您的依赖项重新定位到您自己的包命名空间中。当然，这有一个缺点，即您将增加库的代码大小，但从好的方面来说，您几乎可以保证依赖项的版本，而不会影响您的客户可能使用的任何其他库。
EDIT:回应马库斯·莱昂的评论：
无需捆绑/重新定位的可能解决方案：
- 文档，确保记录您的依赖项以及与以前版本的任何已知冲突 - 没有人真正阅读它
- 通过依赖项管理系统分发您的库...例如 Maven 或 ivy 存储库，这些允许您在一组非常特定的范围（包括上限）中记录您的依赖项 - 仍然可以被覆盖，只是您的客户会知道它们正在做
- 在 MANIFEST.MF 中添加 OSGi 信息 - 仅当您的客户端实际使用 OSGi 时才有用
- 如果您的依赖项是使用 Maven 构建的或者清单文件中有版本信息，您可以编写某种检查例程来扫描这些类路径并检查版本 - 有点极端
最后，要真正确保您拥有所需的依赖项是非常困难的，因为 java 是一种后期绑定语言，您的依赖项（即使是捆绑的）可能会被包含在类路径上的版本之前的不同版本的人覆盖。
注：我最近花了very试图找出为什么我们的一个应用程序无法找到新版本的 log4j 的糟糕一天。原因：有人试图提供帮助，将其捆绑到一个随机的完全不相关的罐子中。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
