I would zip the jar file along with other dependent jars, configuration files and documentation along with a run.bat/run.sh. End user should be able unzip it to any location and edit the run.bat if required (It should run without editing in most of the cases). An installer may be useful if you want to create entries in start menu, desktop, system tray etc.
As a user I prefer unzip and run kind of installation (no start menu entries please). However People outside IT industry may have different preferences. So if the application is largely targeted for developers zip-run.bat route and applications for general public may be installed using a installer.
由于我使用 Maven2 进行构建，因此部署只是小菜一碟：将构建的 jar 复制到服务器上的位置，如果需要更新 jnlp 文件，就完成了。
Well from my point of view the superior distribution mechanism is to use something like ClickOnce, or WebStart technology. You just deploy the version to the server and it gets automatically to the clients when the version is released. Also the Eclipse RCP platform contains UpdateManager that does what WebStart do, but also much more.
Since I am using Maven2 for building, the deployment is just a piece of cake: copy the built jar to the location on the server, update the jnlp file if needed and you are done.
最佳答案取决于平台。 对于 Windows 上的部署，我结合使用 one-jar 和 launch4j。 正确设置我的构建环境确实花了一些时间（主要是 ant 脚本），但现在相当轻松。
The best answer depends on the platform. For deployment on Windows, I have had good results using a combination of one-jar and launch4j. It did take a little while to set up my build environment properly (ant scripts, mostly) but now it's fairly painless.
What's the best way to distribute a Java application? What if the Java application needs to install artifacts to the user's computer? Are there any good Java installation/packaging systems out there?
In my experience (from evaluating a number of options), install4j is a good solution. It creates native installers for any platform, and is specifically geared towards installing Java apps. For details, see "Features" on its website.
install4j is a commercial tool, though. Especially if your needs are relatively simple (just distribute an application and install some artifacts), many other good options exist, including free ones (like izPack or the already mentioned Lauch4j). But you asked for the best way, and to my current knowledge install4j is the one, especially for distributing larger or more complicated Java (EE) apps.
I develop eclipse RCP applications. Normally to start an eclipse application an executable launcher is included. I include the java virtual machine inside the application folder in a /jre sub directory to ensure that the right java version will be used.
Then we package with Inno Setup for installation on the user's machine.
Although I haven't used NSIS (Nullsoft Scriptable Installer System) myself, there are install scripts that will check whether or not the required JRE is installed on the target system.
如果它是真正的具有 GUI 的最终用户应用程序，您应该忽略编写程序的语言 (Java)，并为您选择的每个平台使用本机安装程序。 Mac 用户需要 .dmg，而在 Windows 上则需要 .msi 或 .exe 安装程序。 在 Windows 上，我更喜欢 NullSoft 的 NSIS，只是因为它比 InstallShield 或 InstallAnywhere 更容易让人反感。 在 OSX 上，您可以信赖 JVM 已经存在。 在 Windows 上，如果需要，您需要检查并安装它。 Linux 用户不会运行 Java GUI 应用程序，而少数会运行的人知道如何处理可执行的 .jar。
If it's a real GUI-having end user application you should ignore the lanaguage in which you wrote the program (Java) and use a native installer for each of your chosen platforms. Mac folks want a .dmg and on windows a .msi or a .exe installer is the way to go. On Windows I prefer NSIS from NullSoft only because it's less objectionable than InstallShield or InstallAnywhere. On OSX you can count on the JVM already being there. On Windows you'll need to check and install it for them if necessary. Linux people won't run Java GUI applications, and the few that will, know what to do with an executable .jar.
这取决于您的目标用户的复杂程度。 在大多数情况下，您希望将它们与您正在运行基于 Java 的应用程序这一事实隔离开来。 为他们提供一个本机安装程序，该安装程序可以执行正确的操作（创建开始菜单条目、启动器、注册添加/删除程序等），并且已经捆绑了 Java 运行时（因此用户不需要了解或关心它）。 我想推荐我们的跨平台安装工具，BitRock InstallBuilder。 尽管它不是基于Java的，但它通常用于打包Java应用程序。 它可以轻松地与 Ant 集成，您可以从 Unix/Linux/Mac 构建 Windows 安装程序，反之亦然。 由于生成的安装程序是本机的，因此不需要自解压步骤或目标系统中已存在 JRE，这意味着安装程序更小，并为您省去一些麻烦。 我还想提一下，我们拥有开源项目的免费许可证
It depends on how sophisticated your target users are. In most cases you want to isolate them from the fact that you are running a Java-based app. Give them with a native installer that does the right thing (create start menu entries, launchers, register with add/remove programs, etc.) and already bundles a Java runtime (so the user does not need to know or care about it). I would like to suggest our cross platform installation tool, BitRock InstallBuilder. Although it is not Java-based, it is commonly used to package Java applications. It can be easily integrated with Ant and you can build Windows installers from Unix/Linux/Mac and the other way around. Because the generated installers are native, they do not require a self-extraction step or a JRE to be already present in the target system, which means smaller installers and saves you some headaches. I also would like to mention we have free licenses for open source projects
高级安装程序可以轻松地将java应用程序打包为Windows可执行文件，并且设置方式非常灵活向上。 我发现要将 Java 应用程序分发到 Windows 客户端，这是最简单的方法。
advanced installer makes it easy to package java apps as windows executables, and it's quite flexible in the way you can set it up. I've found that for distributing java applications to windows clients, this is the easiest way to go.
JSmooth 是一个简单的程序，它获取您的 jar 并将其包装在标准 Windows 可执行文件中。 它带有一个简单的 GUI，允许您配置所需的 JVM，将其与应用程序捆绑在一起，或者提供下载它的选项（如果尚未安装）。 您可以按原样发送 exe 文件，也可以将其与可能的依赖项一起压缩（或者让程序在启动时从网络下载额外的依赖项）。 它也是免费的，就像啤酒和演讲一样，这可能（也可能不是）一件好事。
JSmooth is a simple program that takes your jar and wraps it up in a standard windows executable file. It comes with a simple GUI that allows you to configure the required JVM, bundle it with the application or provide an option to download it if it's not already installed. You can send the exe file as is or zip it with possible dependencies (or let the program download the extra dependencies from the net on startup). It's also free, as in beer and speech, which may (or may not) be a good thing.
There are a variety of solutions, depending on your distribution requirements.
Just use a jar. This assumes that the user has the the correct java version installed, otherwise the user will get "class-file format version" exceptions. This is fine for internal distribution inside a company.
Use launch4j and an installer like NSIS. This gives you a lot more control, although the user can still do stupid stuff like un-installing the java runtime. This is probably the most popular approach, and what I currently use.
Use Webstart. This also assumes that the user has the correct java version installed, but it's a lot easier to get going. My experience is that this is fine for tightly controlled intranet environments, but becomes a pain with larger deployments because it has some many weird failures. It may get better with the new plug-in technology in Java 1.7.
Use a native-code compiler like Excelsior JET and distribute as a executable, or wrap it up in an installer. Expensive, and it generally ties you to a slightly older version of java, and there is some pain with dynamic class-loading, but its very effective for large-scale deployment where you need to minimise your support hassles.
发布评论
评论（15）
我会将 jar 文件与其他依赖 jar、配置文件和文档以及 run.bat/run.sh 一起压缩。 最终用户应该能够将其解压缩到任何位置并根据需要编辑 run.bat（在大多数情况下，它应该无需编辑即可运行）。
如果您想在开始菜单、桌面、系统托盘等中创建条目，安装程序可能会很有用。
作为用户，我更喜欢解压缩并运行安装（请不要开始菜单条目）。 然而，IT 行业以外的人可能有不同的偏好。 因此，如果应用程序主要针对开发人员，则可以使用安装程序安装 zip-run.bat 路径和面向公众的应用程序。
I would zip the jar file along with other dependent jars, configuration files and documentation along with a run.bat/run.sh. End user should be able unzip it to any location and edit the run.bat if required (It should run without editing in most of the cases).
An installer may be useful if you want to create entries in start menu, desktop, system tray etc.
As a user I prefer unzip and run kind of installation (no start menu entries please). However People outside IT industry may have different preferences. So if the application is largely targeted for developers zip-run.bat route and applications for general public may be installed using a installer.
installanywhere 很好，但是很贵 - 我还没有找到好的免费的
installanywhere is good but expensive one - i have not found (as) good free one
从我的角度来看，更好的分发机制是使用类似 ClickOnce 或 WebStart 技术。 您只需将版本部署到服务器，当版本发布时，它会自动获取到客户端。
此外，Eclipse RCP 平台还包含 UpdateManager，它可以完成 WebStart 的功能，但还可以做更多的事情。
由于我使用 Maven2 进行构建，因此部署只是小菜一碟：将构建的 jar 复制到服务器上的位置，如果需要更新 jnlp 文件，就完成了。
Well from my point of view the superior distribution mechanism is to use something like ClickOnce, or WebStart technology. You just deploy the version to the server and it gets automatically to the clients when the version is released.
Also the Eclipse RCP platform contains UpdateManager that does what WebStart do, but also much more.
Since I am using Maven2 for building, the deployment is just a piece of cake: copy the built jar to the location on the server, update the jnlp file if needed and you are done.
最佳答案取决于平台。 对于 Windows 上的部署，我结合使用 one-jar 和 launch4j。 正确设置我的构建环境确实花了一些时间（主要是 ant 脚本），但现在相当轻松。
The best answer depends on the platform. For deployment on Windows, I have had good results using a combination of one-jar and launch4j. It did take a little while to set up my build environment properly (ant scripts, mostly) but now it's fairly painless.
根据我的经验（来自 评估许多选项），install4j 是一个不错的选择解决方案。 它为任何平台创建本机安装程序，并且专门用于安装 Java 应用程序。 有关详细信息，请参阅其网站上的“功能”。
不过 install4j 是一个商业工具。 特别是如果您的需求相对简单（只需分发应用程序并安装一些工件），则存在许多其他不错的选择，包括免费的（例如 izPack 或已经提到的 Lauch4j）。 但您要求的是最佳方式，据我目前所知，install4j 就是最好的方式，特别是对于分发更大或更复杂的 Java (EE) 应用程序。
In my experience (from evaluating a number of options), install4j is a good solution. It creates native installers for any platform, and is specifically geared towards installing Java apps. For details, see "Features" on its website.
install4j is a commercial tool, though. Especially if your needs are relatively simple (just distribute an application and install some artifacts), many other good options exist, including free ones (like izPack or the already mentioned Lauch4j). But you asked for the best way, and to my current knowledge install4j is the one, especially for distributing larger or more complicated Java (EE) apps.
我需要一种方法将我的项目及其依赖项打包到单个 jar 文件中。
我使用 Maven2 Assembly 插件找到了我需要的东西： Maven2 程序集插件
这似乎重复了 one-jar 的功能，但不需要额外的配置即可运行。
I needed a way to package my project and its dependencies into a single jar file.
I found what I needed using the Maven2 Assembly plugin: Maven2 Assembly plugin
This appears to duplicate the functionality of one-jar, but requires no additional configuration to get it going.
可执行文件是最好的，但它们受到平台限制，即使用 gcj ： http://gcc.gnu.org/java/ Linux 生成可执行文件并使用 launch4j ： http://launch4j.sourceforge.net/生成 Windows 可执行文件。
要在 Linux 上打包，您可以使用任何 rpm 或 deb 打包程序。 对于 win32，请尝试 http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System
executable files are best but they are platform limited i.e. use gcj : http://gcc.gnu.org/java/ for linux to produce executables and use launch4j : http://launch4j.sourceforge.net/ to produce windows executables.
To package on linux you can use any rpm or deb packager. For win32 try http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System
对于简单的 Java 应用程序，我喜欢使用 Jar。 分发一个用户只需单击即可的文件（Windows）非常简单，或者
恕我直言，当简单性是主要要求时，jar 是最佳选择。
For simple Java apps I like to use Jar's. It is very simple to distribute one file that a user can just click on (Windows), or
IMHO, jar is the way to go when simplicity is a main requirement.
我开发 Eclipse RCP 应用程序。 通常，启动 Eclipse 应用程序时会包含一个可执行启动器。 我将 java 虚拟机包含在 /jre 子目录中的应用程序文件夹中，以确保使用正确的 java 版本。
然后我们用 Inno Setup 打包安装在用户的机器上。
I develop eclipse RCP applications. Normally to start an eclipse application an executable launcher is included. I include the java virtual machine inside the application folder in a /jre sub directory to ensure that the right java version will be used.
Then we package with Inno Setup for installation on the user's machine.
虽然我自己没有使用过 NSIS (Nullsoft Scriptable Installer System)，但是有安装脚本将检查目标系统上是否安装了所需的 JRE。
代码示例和Real World Installers 页面，例如：
（请注意，我没有实际使用过任何脚本，所以请不要将其视为认可。）
Although I haven't used NSIS (Nullsoft Scriptable Installer System) myself, there are install scripts that will check whether or not the required JRE is installed on the target system.
Many sample scripts are available from the Code Examples and Real World Installers pages, such as:
(Please note that I haven't actually used any of the scripts, so please don't take it as an endorsement.)
如果它是真正的具有 GUI 的最终用户应用程序，您应该忽略编写程序的语言 (Java)，并为您选择的每个平台使用本机安装程序。 Mac 用户需要 .dmg，而在 Windows 上则需要 .msi 或 .exe 安装程序。 在 Windows 上，我更喜欢 NullSoft 的 NSIS，只是因为它比 InstallShield 或 InstallAnywhere 更容易让人反感。 在 OSX 上，您可以信赖 JVM 已经存在。 在 Windows 上，如果需要，您需要检查并安装它。 Linux 用户不会运行 Java GUI 应用程序，而少数会运行的人知道如何处理可执行的 .jar。
If it's a real GUI-having end user application you should ignore the lanaguage in which you wrote the program (Java) and use a native installer for each of your chosen platforms. Mac folks want a .dmg and on windows a .msi or a .exe installer is the way to go. On Windows I prefer NSIS from NullSoft only because it's less objectionable than InstallShield or InstallAnywhere. On OSX you can count on the JVM already being there. On Windows you'll need to check and install it for them if necessary. Linux people won't run Java GUI applications, and the few that will, know what to do with an executable .jar.
这取决于您的目标用户的复杂程度。 在大多数情况下，您希望将它们与您正在运行基于 Java 的应用程序这一事实隔离开来。 为他们提供一个本机安装程序，该安装程序可以执行正确的操作（创建开始菜单条目、启动器、注册添加/删除程序等），并且已经捆绑了 Java 运行时（因此用户不需要了解或关心它）。 我想推荐我们的跨平台安装工具，BitRock InstallBuilder。 尽管它不是基于Java的，但它通常用于打包Java应用程序。 它可以轻松地与 Ant 集成，您可以从 Unix/Linux/Mac 构建 Windows 安装程序，反之亦然。 由于生成的安装程序是本机的，因此不需要自解压步骤或目标系统中已存在 JRE，这意味着安装程序更小，并为您省去一些麻烦。 我还想提一下，我们拥有开源项目的免费许可证
It depends on how sophisticated your target users are. In most cases you want to isolate them from the fact that you are running a Java-based app. Give them with a native installer that does the right thing (create start menu entries, launchers, register with add/remove programs, etc.) and already bundles a Java runtime (so the user does not need to know or care about it). I would like to suggest our cross platform installation tool, BitRock InstallBuilder. Although it is not Java-based, it is commonly used to package Java applications. It can be easily integrated with Ant and you can build Windows installers from Unix/Linux/Mac and the other way around. Because the generated installers are native, they do not require a self-extraction step or a JRE to be already present in the target system, which means smaller installers and saves you some headaches. I also would like to mention we have free licenses for open source projects
高级安装程序可以轻松地将java应用程序打包为Windows可执行文件，并且设置方式非常灵活向上。 我发现要将 Java 应用程序分发到 Windows 客户端，这是最简单的方法。
advanced installer makes it easy to package java apps as windows executables, and it's quite flexible in the way you can set it up. I've found that for distributing java applications to windows clients, this is the easiest way to go.
JSmooth 是一个简单的程序，它获取您的 jar 并将其包装在标准 Windows 可执行文件中。 它带有一个简单的 GUI，允许您配置所需的 JVM，将其与应用程序捆绑在一起，或者提供下载它的选项（如果尚未安装）。 您可以按原样发送 exe 文件，也可以将其与可能的依赖项一起压缩（或者让程序在启动时从网络下载额外的依赖项）。 它也是免费的，就像啤酒和演讲一样，这可能（也可能不是）一件好事。
JSmooth is a simple program that takes your jar and wraps it up in a standard windows executable file. It comes with a simple GUI that allows you to configure the required JVM, bundle it with the application or provide an option to download it if it's not already installed. You can send the exe file as is or zip it with possible dependencies (or let the program download the extra dependencies from the net on startup). It's also free, as in beer and speech, which may (or may not) be a good thing.
有多种解决方案，具体取决于您的分发要求。
只需使用一个罐子即可。 这假设用户安装了正确的java版本，否则用户将得到“类文件格式版本”异常。 这对于公司内部分发来说是很好的。
使用 launch4j 和 NSIS 等安装程序。 这给了你更多的控制权，尽管用户仍然可以做一些愚蠢的事情，比如卸载 java 运行时。 这可能是最流行的方法，也是我目前使用的方法。
使用网络启动。 这还假设用户安装了正确的 java 版本，但上手要容易得多。 我的经验是，这对于严格控制的内联网环境来说很好，但对于大型部署来说却很痛苦，因为它会出现一些奇怪的故障。 Java 1.7 中的新插件技术可能会变得更好。
使用 Excelsior JET 等本机代码编译器并作为可执行文件分发，或将其包装在安装程序中。 价格昂贵，而且它通常会让您使用稍旧版本的 java，并且动态类加载会带来一些痛苦，但它对于需要最大程度地减少支持麻烦的大规模部署非常有效。
There are a variety of solutions, depending on your distribution requirements.
Just use a jar. This assumes that the user has the the correct java version installed, otherwise the user will get "class-file format version" exceptions. This is fine for internal distribution inside a company.
Use launch4j and an installer like NSIS. This gives you a lot more control, although the user can still do stupid stuff like un-installing the java runtime. This is probably the most popular approach, and what I currently use.
Use Webstart. This also assumes that the user has the correct java version installed, but it's a lot easier to get going. My experience is that this is fine for tightly controlled intranet environments, but becomes a pain with larger deployments because it has some many weird failures. It may get better with the new plug-in technology in Java 1.7.
Use a native-code compiler like Excelsior JET and distribute as a executable, or wrap it up in an installer. Expensive, and it generally ties you to a slightly older version of java, and there is some pain with dynamic class-loading, but its very effective for large-scale deployment where you need to minimise your support hassles.