install4j
Best Java Installation Tool
Please see the change log for a detailed list of changes. For a discussion of breaking changes when migrating from install4j 5.1, please see this blog post.
install4j 6.0 introduces the following notable new features:
install4j 6 introduces a fast edit-compile-test loop with the new "Test installer" tool bar button. Instead of building the entire media file, it just recompiles scripts, screens and actions and updates an existing media file.
When you click on "Test installer", the installer is launched automatically after a short compilation phase.
The first time before using the "Test installer" feature, or whenever you need changed files or launchers in the installer, you build the first media file that runs on your current platform. To select a particular media file, you can reorder the list of media files correspondingly.
Properties file actions now help you with reading, writing and manipulating properties files.
The "Read a properties file" action reads a properties file to an installer variable. Arbitrary encodings as well the special java.util.Properties format are supported.
The "Write properties to file" action can not only write properties to a file, it also merges new or updated property definitions into an existing property file.
The property definitions can come from a variety of sources. You can provide an installer variable of type java.util.Map, enter the property definitions directly in the install4j IDE or specify yet another properties file.
Unlike the simple java.util.Properties class, the actions in install4j can handle comments on property definitions and can optionally sort property keys.
The new JDBC file actions can check database connections and execute SQL queries.
The "Check JDBC connection" action tests whether the connection to a configured JDBC database can be established. The action fails if an error occurs.
New XML file actions have been added for common use cases.
The "Insert XML fragment into XML files" action allows you to merge new nodes in places defined by an XPath expression and a configurable insertion mode. The XML fragment can be entered directly in the install4j IDE, or an XML file can be read from which the children of the root element are extracted.
New HTTP and network actions make it easier to deal with servers.
The "HTTP request" action can perform all types of HTTP requests including REST operations. Response body, response code and response headers can be saved to installer variables.
DMGs on Mac OS X. In previous versions, install4j could only write DMGs in ISO format. This was only suitable for installers, because the contained files had to be compressed.
install4j 6 can write DMGs in UDIF-compressed HFS+. This means that archives on Mac OS X can now also be written as DMG. The old .tgz option is still available and may still be preferable for command line and server applications.
Improved launchers on Mac OS X. The names of GUI launchers on Mac OS X can now be internationalized. This uses the i18n mechanism of application bundles on Mac OS X. All you have to do is to specify the launcher name as an i18n variable. For each configured language in your project a localized name will be written to the application bundle.
On Mac OS X, the launcher name may have to be more descriptive than on other platforms, so install4j 6 offers the possibility to specify a different launcher name on Mac OS X, both for launchers and installer applications.
Many other improvements on Mac OS X. In this release several features that were missing on Mac OS X with respect to Windows have been implemented.
Oracle JREs for Mac OS X have been supported since install4j 5.1 but the JRE bundle creation wizard was previously not available on Mac OS X. This has been implemented in install4j 6 together with the ability to create unpacked JRE bundles for archives.
Java code editor improvements. Until now, reusing code across different scripts could only be done with custom code that was compiled in your Java IDE and added on the "Installer->Custom code & resources" step.
In install4j 6, a script for defining static fields and methods has been added on that step.
Configurable DPI-awareness setting for Windows launchers. By default, Windows launchers are scaled up for DPI settings larger than 100%. If your launcher is DPI aware, you can enable DPI awareness in the launcher wizard. This will add an entry to the executable manifest that enables your GUI to be shown with high resolution.
If you do not explicitly handle high-DPI cases, this will most likely lead to unacceptable results, so this setting is disabled by default and corresponds to the previous behavior of install4j launchers.
Splash screen improvements. The minimum Java version for launchers is now Java 6, so the custom splash screen implementation for Unix and Mac OS X has been replaced with the Java splash screen.
This means that the splash screen is now displayed much faster on non-Windows platforms than before. The text line overlays and the splash screen manipulation API now work with the Java splash screen.
The splash screen settings in the launcher wizard have been adjusted to reflect these new realities.
On Windows, the native splash screen is optionally still available. It is displayed even faster than the Java splash screen, but does not handle transparent images.
RPM improvements. You can now configure the operating system and the architecture for RPM files.
Hidden variables can be configured in the IDE. If an installer variable contains sensitive information that should not be written to the log file, you previously had to call a method in the API. Now you can configure this setting for predefined installer variables in the install4j IDE.
The new "Return to parent screen" failure strategy makes it easy to perform long-running input validations in actions. If an error occurs, the current screen will be shown again. Previously, this required using the API.
The new "Disable JRE bundling" build option lets you reduce compile times for testing purposes or allow compilation in the case where the configured JRE bundles are not locally available. The option is also available from the command line or in the ant and gradle integrations.
Command line option to run services in a terminal. For debug purposes, it can often be desirable to run a service directly in a terminal instead of installing it and starting it in the background. Previously, you had to create another command line launcher.
In install4j 6, service launchers support two direct run modes:
Support for very large installers. Previously, installers could not be bigger than 2GB. In install4j 6, there are new platform-dependent limits:
A gradle plugin was added. A simple usage of the plugin looks like this:
buildscript { repositories { maven { url 'http://maven.ej-technologies.com/repository' } } dependencies { classpath group: 'com.install4j', name: 'gradle-plugin', version: '6.0' } } install4j { installDir = file('/opt/install4j') } task media(type: com.install4j.gradle.Install4jTask) { projectFile = file('myProject.install4j') }
All customizations that are available for the ant task are also available for the gradle plugin.