ej-technologies - What's new in install4j 6.0

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 cannot 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.

Finally, the "Remove keys from properties file" action deletes selected properties from a properties file, while preserving comments and key ordering.

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.

With the "Execute SQL query" action you can retrieve data from a JDBC database and store the result in an installer variable. The action supports multiple rows and columns, and provides easy access to values if only one row, one column or a single value are returned by the SQL statement.

If you want to execute multiple SQL statements without the need to process the return values, the "Execute SQL script" action performs this task for you. You can enter the SQL statements directly in the install4j IDE or read them from a file.

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.

The "Remove nodes from XML files" action is the complementary action and removes nodes that match a specified XPath expression.

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.

Form data can be entered conveniently and is added as URL query parameters or as encoded data in the request body, depending on the HTTP request method.

If a rollback occurs, you can specify a separate request to undo any changes on the server.

The new "Upload file" action has been added to provide complementary functionality to the existing "Download file" action.

With the new "Wait for socket" action, you can wait for arbitrary servers to become available and not just for HTTP servers which is handled by the existing "Wait for HTTP server" action.

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.

You can now add additional top-level files to DMGs. This could be a README file or an additional installer. Most importantly, you can use this feature to style the Finder window for the mounted DMG.

Creating the .DS_Store file for styling the Finder window is explained in detail in a new help topic. install4j ships with background images for archives and installers in the resources/macos directory that you can use, but the .DS_Store file must be created for each project, because it references a unique project-specific volume ID.

For DMGs, the volume name and - for installers - the name of the contained installer can now be customized. If the installer name is entered with an i18n variable, the file name will be localized.

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.

The uninstaller name that was previously fixed can now be set in the install4j IDE.

To assign an icon to a Mac OS X launcher, you previously had to create an ICNS icon file. install4j 6 can generate the ICNS file from the cross-platform icon images, just like for Windows. Note that you should supply at least an image of size 128x128 pixels for this feature.

Mac OS X launchers can now create a debug log, just like Windows launchers. To enable log file creation, you have to specify the environment variable INSTALL4J_LOG=yes. You can do that by calling launchctl setenv INSTALL4J_LOG=yes in a terminal. By executing open $TMPDIR you can then show the directory that contains the log file whose name starts with "i4j"

Starting with install4j 6, command line launchers and services are included in single-bundle archives and installers. Previously, only the selected GUI launcher was available.

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.

Retina icons are now supported for all image properties. Next to the selected image file, create another image file with twice the resolution and append "@2x" to its name, then the install4j compiler will pick it up and use it on Mac OS X retina displays.

The "Check for running processes" action now works on Mac OS as well. If a launcher is still running, installation or uninstallation will alert that the applications should be closed first. The class com.install4j.api.macos.MacProcesses was added to the API so that you can list and close Mac OS X processes programmatically as well.

Other features that previously only worked on Windows have been extended to Mac OS X. This includes the "Reboot computer" action and the installer variables "sys.appDataDir", "sys.localAppdataDir", "sys.docsDir", "sys.fontsDir" and "sys.programsDir".

Finally, the updater template has been adjusted so that updaters work with Mac OS X single bundle archives.

  
      Response files improvements. Variable definitions in response files can now have comments. The
      comments are written to the response file and are configurable in the IDE and through the API.

Response files are now sorted alphabetically and variables that have been read from a response file are now registered automatically as response file variables. The "Load a response file" action now has a property to revert this change to the previous behavior and a new "Overwrite strategy" property. The latter is set by default so that variables that have been set on the command line are not overridden.

The "Create a response file" action is now more flexible with respect to the selection of installer variables that will be written to the response file. In addition to the exclusive filter, there is now also an inclusive filter mode.

The new "Modify a response file" action allows you to update all variables in an existing response file without losing previous variable definitions. This can be useful in custom installer applications. Installer variables for which no value is available in the current installer application will be kept as is. You can also add selected installer variables to an existing response file.

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.

You can declare fields, methods and even classes, and as long as they are declared as "static", they can be referenced by other scripts in your project.

All static definitions will be suggested by code completion and can be used without any prefix in all other scripts editors.

When you code-complete an abstract class or an interface, stubs for all abstract methods are inserted automatically. When auto-completing a class that is not in the default or explicit imports, an import statement will be added instead of using the fully qualified class name.

install4j now shows the correct line numbers for script compilation errors and script runtime exception stack traces. Previously, the line number referred to generated source code and did not help with finding the exact location of an error. In stack traces, line numbers that only exist in generated source code are prefixed with an asterisk.

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:

With the argument /run on Windows or run on other platforms you start the service executable in the foreground. All output is printed directly on the terminal.
With the argument /run-redirect on Windows or run-redirect on other platforms you start the service executable in the foreground, but keep the configured redirection.

Support for very large installers. Previously, installers could not be bigger than 2GB. In install4j 6, there are new platform-dependent limits:

On Windows there is a 4GB limit due to the fact that executables (even 64-bit executables) cannot be larger than 4GB.
On Mac OS X and on Linux/Unix there is no relevant limit to the size of the installer.
If you use external data files, there is no relevant limit on any platform.

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.