建造一个巨大的jar子而不是几个小jar子的优点/缺点？
我已经看到像http://one-jar.sourceforge.net/和http://fjep.sourceforge.net/index.html这样的程序将你的应用程序jar和任何依赖项推送到一个可执行的jar中。
这样做的主要原因是什么？
对于：
- 更容易分配，
- 使类路径问题消失，
- 甚至可以在Ms PowerPoint演示文稿中打包作为可点击的图标，可能OpenOffice也可以处理它。
反对：
- 困难的包装 – 有时你遇到了一个角落的情况，例如：如何打包原生扩展，
- 需要额外的构建步骤，
- 生成更大的jar子，
- 可以违反图书馆的许可协议，
- 杀死了图书馆重用的概念，
- 进行更新和
- 调试（因为额外的类路径加载器）更难。
因此，一般来说，它确实是快速原型设计的好方法，但如果在更大的项目中使用，可能会遇到困难。
我在工作场所看到的一个正当理由是，供应商提供了需要在类路径中的原始版本之前的修补程序jar。
但是，此应用程序是通过java webstart（jnlp）启动的，从java版本6开始，不再保证jar文件依赖项的顺序。
因此，确保重复的类文件的顺序正确的唯一方法是将它们重新打包到超级jar中，保留最新的修补类文件并丢弃旧的重复项。
适用于依赖项的再分发许可证是构建“超级”jar的一个主要原因。 当一个人创造一个“超级”jar子时，通过“超级”jar子的分配发生任何依赖性的分配。 在案例法没有充分涵盖这种情况的地区，人们可能会承担责任。
此外，一些商业上获得的依赖关系可能会禁止重新打包依赖关系，尤其是在原始分布不受保护的情况下。
PS：这不是法律建议。 任何阅读此内容并依据此进行商业决策的人都应该咨询律师。
对于：
- 捆绑库和本机代码
- 确保classpath元素的运行时顺序正确
- 无需安装人员
反对：
- 新的顶级类加载器可能会引入在正常开发周期中看不到的问题
- 在不同的许可条款下重新包装图书馆的合法性
一般来说，如果它是一个小实用程序应用程序，我会将它捆绑到一个jar中。 对于较大的应用程序（可能需要安装程序），或者如果它是供其他人使用的库，我不会打扰。 这将是可能破坏的事物链中的另一个环节。
FTW发行！ 用户汇总到一个用户就容易多了。