你应该 不 捆绑任何第三方jar文件到您自己的罐子作为一位超级罐子，但它是很好的，包括所有所需在分发比方说在lib目录或什么都罐子的副本。
这样做的主要原因是您的客户可能正在使用某种形式的依赖管理系统（maven / ivy等），并且提供实际上不属于您的项目的包和类会使这些方案无效。
有一种选择，那就是使用诸如maven shade plugin之类的东西将您的依赖项重新定位到您自己的包名称空间中。当然，这样做的缺点是您将增加库的代码大小，但从好的方面来说，您几乎可以保证依赖版本，而不会影响客户端可能正在使用的任何其他库。
编辑： 回应马库斯·莱昂评论：
没有捆绑/重新定位的可能解决方案：
- 文档，确保您记录依赖项以及与先前版本的任何已知冲突-没人真正读过它
- 通过依赖管理的系统来分发您的库…像maven或ivy repo，它们使您能够在非常特定的范围内（包括上限）记录依赖项，即您的客户知道它们仍然可以被覆盖在做
- 在MANIFEST.MF中添加OSGi信息-仅在您的客户端实际使用OSGi时有用
- 如果您的依赖项是使用maven构建的，或者在清单文件中包含版本信息，则可以编写某种检查例程，以扫描这些类路径并检查其中的版本-有点极端
最后，要真正确保您具有所需的依赖关系非常困难，因为Java是一种后期绑定语言，因此有可能使您的依赖关系（即使是捆绑在一起）被包括在类路径上的其他版本的人覆盖了（即使是捆绑在一起的）。
注意：我最近度过了 非常
糟糕的一天，试图找出为什么我们的一个应用程序未能找到新版本的log4j。原因：有人试图提供帮助，将其捆绑到一个随机的，完全无关的广口瓶中。
