What's New in install4j 5.0

Change release:

Please see the change log for a detailed list of changes. For a discussion of breaking changes when migrating from install4j 4, please see this blog post.

install4j 5.0 introduces the following notable new features:

Merged projects. It is now possible to merge other sub-projects into a project. The following elements can be merged:
  • Files can be merged by creating file sets with the same name
  • Launchers can be merged on demand
  • Custom installer applications can be merged on demand
  • Screens and actions can be merged by adding links into the merged projects
On the screens & actions tab, you can add links into other projects:
Improved elevation of privileges on Windows and Mac OS X. There is a new Request privileges action that replaces the setting for the execution level in the Windows media wizard and the "Require admin user" action. This new action can now restart the main installation process at any point with full privileges or start a helper process with full privileges. The action is now added to all projects by default, the screen shot below shows the default settings of all properties.
Usually, you do not want to execute the installed application or an internet browser with full privileges at the end of the installation. If the main installation process is restarted with full privileges, the original process is retained for executing particular actions with the original privileges, like the "Execute launcher" action or the "Show URL" action. Service actions are automatically pushed to the elevated helper process, if it exists. For the important "Run executable or batch file" action, you can choose whether you want to execute it with full privileges or as the original user.
Major improvements for installer variables, compiler variables and i18n messages. Installer variables can now be pre-defined in the install4j IDE for each installer application. You can categorize variables in a tree and assign descriptions that are shown in the variable selector. These improvements are also available for compiler variables.
On the screens & actions tab, installer applications have a new "Installer variables" configuration tab that gives access to the pre-definition of installer variables as well as to the list of bound installer variables that were detected in the installer application. For each bound variable, a tree of back traces to all bindings is shown. From that tree, you can easily jump to the selected element.
There is an easy workflow for pre-defining and documenting bound variables:
The variable selector has been split into different dialogs for each variable type. The variable selector for installer variables shows you pre-defined variables mixed with system variables. The description explains the content of the variable, type and initial value are shown if available. Many new system variables have been added. They are now documented with descriptions and are categorized for easy browsing. Bound variables are also shown in the installer variables selector.
Custom localization files can now be created and edited directly from the install4j IDE. Overriding system messages is especially easy in the built-in editor.
The variable selector for i18n messages shows system and custom messages together, you see the messages in the principal language and the "Edit" link gives you quick access to the editor dialog, so you can easily add messages on the fly.
All variable selectors now insert an expression that is appropriate for the context in which they were invoked. For example, in a script, the i18n message selector inserts ${i18n:databaseError("arg 0")} in a text field and context.getMessage("databaseError", new Object[] {"arg 0"}) in a script.
More flexible and usable IDs. When writing scripts that reference elements by IDs, such as context.getInstallationComponentById("41").setSelected(true), the ID of the concerned element is only visible in another screen and cannot be easily accessed. The new ID selector dialog shows all elements with IDs in your project and inserts the ID of the selected element.
Numeric IDs do not make for legible code. Now you can assign custom IDs to all elements. A custom ID must not start with a number and is valid in addition to the automatically assigned numeric ID. This means that you can start assigning custom IDs in your existing projects without breaking any existing code.
Improvements for actions that operate on files. Previously, actions like the "Copy file or directory" action or the "Replace installer variables in a text file" actions only operated on a single file. Now you can specify multiple files or directories for such actions.
For actions that operate recursively on files, there are now "File filter" and "Directory filter" properties that allow you to specify complex conditions on which files should be processed.
Improvements for form components. Form screens now have layout groups. With horizontal and vertical layout groups you can create flexible layouts. In particular, you can now arrange form components side-by-side. For example, the following configuration:
leads to this layout:
Also new in this release are tab groups. You add a tabbed pane and single tabs as you would add new layout groups:
To each single tab, you can add any number of components or layout groups.
The above configuration results in the following layout:
Layout groups and tabs have visibility scripts and can be disabled making it easy to hide or disable several form components at once.
All form components with leading labels now have a "Help text" property that allows you to display quick help for your users. If you enter some text or an HTML fragment for a property, a tool-tip label with a help icon will be added on the right side.
Launcher integration for custom installer applications. Previously, the only way to start a custom installer application such as an updater, was by using the com.install4j.api.launcher.ApplicationLauncher API from your own code. Now, you can launch custom installer applications automatically by configuring the new "Launcher integrations" tab for the installer application. You can insert the custom installer application at startup or when the first window is shown and you can launch it only if the update schedule registry (like "once a month") requires it. Alternatively, you can use it as a "first run" setup wizard for archives, where no installer is executed.
For more flexibility, you may still want to launch custom installer applications programatically from your own code. For this purpose, an integration wizard has been added on the same "Launcher integration" tab. The integration wizard collects the requirements and presents you with a code snippet that you can copy and paste to your own code.
Previously, custom installer applications were always started in a new process. Now, you can also launch them in the same process. There is a new API method in com.install4j.api.launcher.ApplicationLauncher for that purpose, the launcher integration in the install4j IDE defaults to in-process invocations. This makes custom installer applications much more attractive as configuration wizards that can be used in your own GUI application.
Improvements for the auto-update functionality. The update descriptor file updates.xml that is generated by a build has always had additional functionality that was previously only accessible if you modified the file manually after the build. Now all such features are configurable on the new Installer->Auto-Update Options tab in the install4j IDE. In addition, comments are now localizable. The download URL is now defined for the whole project and "Check for update" actions in updater templates reference that URL with the new compiler variable sys.updatesUrl.
The media file wizard allows you to override some of these project settings. You can specify IDs of discontinued media file that will be updated to this media file. Previously this would have required a structural modification of the updates.xml update descriptor file.
Extensive support for Windows user accounts. Working with specific Windows users accounts is made possible with the new "Windows user selector" form component. Optionally, local users can also be created by that form component. See the "hello" sample project for an example of how you can choose or create a user for a service.
Specific users or groups are selected in the native chooser dialog.
For programmatic creation or Windows user accounts, the com.install4j.api.windows.WinUser class has been added to the API. The "Install a service" action and actions that assign Windows rights let you set a specific user account for the action. The "Account" property of the "Install a service" action also provides several well-known users directly,
Improvements for service actions. Service actions now also support Windows service executables that were not generated by install4j. If you set the "Service" property of the service actions to "Other executable", an executable and a service name can be configured. In this way, you can also install a generated service multiple times with user-specified service names.
The "Windows priority" and "Keep current account" properties visible above also add important new features to the service installation. All service options have been moved from the launcher wizard to the "Install a service" action. On Mac OS X, the modern launchd subsystem is now used for services instead of the startup items subsystem. For non-service startup items, a new "Add a startup executable on Windows and OS X" action has been added that handles both Windows and Mac OS X.
Improved handling of custom code and resources. Sometimes you need access to files before the "Install files" action has run. Until now, this was only possible with difficult workarounds. In this release, the Installer->Custom code & Resources tab handles both custom code for your screens, actions and scripts as well as resource files like DLLs or batch files that are required before any files are installed.
Previously, all custom code was packed into a single user.jar file. In this release, the single user.jar file will only be created for directory and single class file entries in the custom code. JAR files will be extracted unmodified to the .install4j/user directory. This directory is available from the new sys.resourceDir installer variable.
Custom code will never be packaged twice. If the same JAR file should be installed, it will be moved by the "Install files" action from the .install4j/user directory where the custom code has been initially extracted to its final target directory. The old "Use installed JAR files where possible" option for custom code is no longer necessary and has been removed.
Corruption detection and checksum verification for installers and downloaded components. Corruption detection is now implemented on several levels and delivers informative error messages to the user upfront.
MD5 checksums are now calculated during the compilation and can be checked by download actions. Just upload the generated md5sums file together with your update installers and select the "Check for md5sums" property for the "Download file" action in your updater. MD5 checksums are also verified for downloaded data files of installation components.
Support for Windows processes. It is now possible to list, soft-close and terminate running processes programatically with the new com.install4j.api.windows.WinProcesses class. In addition, the new "Check for running processes" action allows you to configure processes that need to be closed in the install4j IDE:
Depending on the close strategy, the user can close processes manually, try to soft-close them (sending a WM_QUIT message to the window) or forcibly terminate them if the soft-close fails. This dialog is also displayed by the "Install Files" action, however without the option to close the processes.
Improvements for file distribution. There is a new Files->File Options tab where you can configure global options for the distribution tree. Some of these options can then be overridden for each entry in the distribution tree.
The runtime is now shrunk to exclude all unused classes. API usages in your generated launchers are considered for this operation. You can disable this feature on The General Settings->Media File Options tab. Also on that tab, you can specify that the compiler should try to generate common media files where possible. For example, if you have multiple media files with that should be distributed on a CD or DVD, you can choose the external data file option in the media wizard and try to generated common data files in order to reduce the necessary disk space.
The new Download and install component action allows you to install a downloadable installation component later on. This is especially useful if you want to add a custom installer application for downloading components at some later time.
Improvements for JRE bundling. If you create your own JRE bundles, you will find the new command line tool for creating JRE bundles helpful. A typical invocation is simply
createbundle c:\Program Files\Java\jre6
With command line arguments, you can customize the output directory, the JRE version and the custom ID if you have more than one JRE bundle for the same platform and version. An Apache Ant task (com.install4j.CreateBundleTask) for creating JRE bundles is also available in bin/ant.jar. The JRE bundle wizard in the install4j IDE (Project->Create a JRE Bundle) has been improved in several areas.
In the "Bundled JRE" step of the media file wizard you can now easily move a JRE bundle that was downloaded from ej-technologies' server to another directory and use a manual entry with the target path. This commonly occurs when you want to place the JRE bundle under version control. In addition, it is now possible to install JREs only if no other suitable JRE is found.
Many new actions have been added:
  • The Create Windows URL link action creates links to arbitrary URLs in arbitrary locations.
  • The Read value from XML file action complements the existing "Replace value in XML" file action.
  • The Read a key from the Java preference store and Read a value from the Windows registry actions complement the existing actions that perform a write operation.
  • The Wait for HTTP port action is useful if you need to wait for an HTTP server to start up before you can proceed.
  • The Download and install component action was discussed above.
  • The Create a ZIP file action creates a ZIP file from selected files and directories. File filter and directory filter scripts are available. The complementary Extract a ZIP file action extracts selected files from a ZIP file. With these two actions, it is easy to modify the contents of ZIP files.
  • Desktop integration on Mac OS X is improved with the Add an executable to the dock action and the Add a startup executable on Windows and OS X.
Wizard index panel. In complex installers that go through different phases, you can now display a wizard index panel on the left side that shows the overall progress. Configuring the index pane is possible for each screen on the Installer->Screens & Actions tab.
The wizard index is displayed for all non-banner screens. Its background image and background color are configurable, so you can add your own branding. The current index remains active until you change the index key, set a new index or remove the index altogether. For complex operations, you can use the com.install4j.api.context.WizardIndex class in the API to configure dynamic indices in the pre-activation scripts of screens.
Similar to the wizard index, the title bar of all non-banner screens is now more flexible. The background image can overlap with the title text, and it can be pinned to arbitrary anchors in the title pane. In addition, you can now set the background and foreground colors of the title bar.
Debian archives. In addition to RPM archives, install4j can now also generate Debian (.deb) archives that are used on Debian-based Linux distributions like Ubuntu. Several .deb-file specific options are configurable in the media wizard.