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