Category: install4j

Migrating to install4j 9

In nearly all cases, migrating to install4j 9 just means opening and saving your project with the install4j 9 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

  • The minimum Java version for the install4j runtime is now Java 1.8. Java 1.7 is no longer supported.
  • The install4j compiler and IDE now require at least Java 11. This is only relevant on Linux and Unix where no JRE is bundled.
  • “Install files” action: The “Update bundled” JRE property has been removed. A bundled JREs is now always updated if the update installer also includes a bundled JRE. The ability to switch this off offers no benefit and has the potential to create severe problems during sequential upgrades. If you had this property selected, you can restore the previous behavior by defining the VM parameter -Dinstall4j.preventJreBundleUpdate=true in the installer.
  • “HTTP request” action: In previous versions, if an error occurred, the response code variable and the response header variables were not set. This error has been corrected in install4j 9, but it changes the semantics of the installer variables.
  • The installer variable sys.appdataDir was previously undefined on Unix, it now returns the value of the environment variable XDG_DATA_HOME ( ~/.local/share ) on Unix.
  • Shared JREs (Windows and Unix) now have a sharing ID. This has become necessary because there is no universal definition of a JRE anymore so the scope of sharing has to be restricted. Consequently, shared JREs are now installed in different locations than before. Also, the user-specific root directories have changed to ~/.local/share/i4j_jres on Unix and %APPDATA%\Local\Programs\Common\i4j_jres on Windows. Shared JREs are now preferred to public JREs on Unix.
  • The “Execute launcher” action always executed the selected launcher without elevation. This does not work for launchers that require privileges themselves. Since install4j 9, the action respects the “Action elevation type” property of the action. This changes the behavior of the action if you have changed the “Action elevation type” property from its default value of “Do not elevate” to another property value.
  • The auto-update integration for background update downloaders in the launcher wizard behaves differently if the “Unattended mode with progress dialog” mode is selected: It now shows errors and alerts in the update installer where previously any error would lead to a silent failure. If this change is not acceptable for you, you can add the VM parameter -Dinstall4j.noAlerts=true to the “VM parameters” property of the installer.
  • Installer applications that have not been started in-process by launchers now set the system property jdk.lang.Process.allowAmbiguousCommands=false to avoid cmd.exe injections. In unattended and console mode, installers applications already behaved that way because they use a security manager. Some quoting strategies or arguments that worked before might stop working in GUI mode because of that change. To revert to the previous behavior, set the VM parameter -D jdk.lang.Process.allowAmbiguousCommands=true for the installer application.
  • The JRE version cache on Linux/Unix is now located in .cache/install4j/jres instead of the file ~/.install4j .
  • Config files, cached files and pre-crated JRE bundles have new platform-specific locations instead of being stored in ~/.install4j<version> . On Windows, all directories are located below %LOCALAPPDATA%/install4j/v<version> . On macOS, ~/Library/Application Support/install4j/v<version> is used for config files as well as pre-created JRE bundles and ~/Library/Caches/install4j/v<version> is used for cached files. On Linux and Unix, .config/install4j/v<version> is used for config files, .caches/install4j/v<version> for caches and .local/share/install4j/v<version> for pre-created JRE bundles. The environment variables XDG_CONFIG_HOME , XDG_CACHE_HOME and XDG_DATA_HOME modify the roots of these directories, respectively.
  • In previous versions, Linux/Unix installers created the installation directory with the default umask. Since install4j 9, the default Unix directory mode configured in the “Files->File Options” view or the overridden mode configured for the “Installation directory” node in the distribution tree is used.

Migrating to install4j 8

In nearly all cases, migrating to install4j 8 just means opening and saving your project with the install4j 8 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

  • The unattended installer does not ignore file installation failures anymore but fails at the first file installation failure. To get the old behavior, start the installer with the -nofilefailures argument. To permanently set this mode, add -Dinstall4j.noFileFailures=true to the “VM parameters” property of the installer.
  • When using the VM parameters -Dinstall4j.alternativeLogFile=<path> and its new alias -Dinstallj4.log=<path>
    now imply -Dinstall4j.keepLog=true , meaning that the log file is no longer deleted in case of a successful execution of the installer application.
  • The default file name of the error log for Windows installers has changed from error.log to ${compiler:sys.mediaFileName}_error.log . You can restore the old file name with the new “Log file for stderr” property of the installer.
  • In bean properties with an array type, installer variables with collection values are expanded as separate array elements. Previously this was only implemented if the installer variables had array values. In the API, this new behavior affects the AbstractBean.replaceVariables(...) methods with array parameters. If you rely on the toString() replacement of collections, you have to change the types of the related installer variables.
  • Variable names for all built-in variable systems can no longer contain the character sequence ?: which is now used for specifying default values for missing variables.
  • FormEnvironment.getId(...) now returns the display ID of the form component rather than the automatic ID. If you were checking for an explicit automatic ID and also defined a custom ID for a form component, that code will now fail.
  • The “Read text from file” action will now fail if an error occurred. Previously it always succeeded.
  • The compiler variable sys.platform now contains the value windows-x32 for 32-bit Windows media files instead of windows . For 64-bit Windows media files it remains windows-x64 .
  • The “Customize project defaults->Installer custom script” step of the Unix/Linux GUI installer media wizard has been removed. The custom script is now configured on the installer in the “Installer->Screens & Actions” step. The simple case where there is only one Unix/Linux GUI installer is migrated correctly. However, if you used different customizations for different Unix/Linux GUI installers, the migration will be incomplete and you have to solve it with compiler variables.
  • For Linux/Unix installers, the umask is now set to 0022 to allow execution by all users. This can be changed by setting the compiler variable sys.ext.installerUmask to another mask value or to false to prevent executing any umask command in the installer script.

Automation sandboxing in macOS 10.14

macOS 10.14 introduces automation sandboxing as part of a new push for security. This change impacts installers generated with install4j prior to 7.0.8, because they use AppleScript to perform a variety of tasks. The authorization dialogs from the new sandboxing mechanims are undesirable for an installer and once a permission is denied it is difficult to reauthorize it.

To solve this problem, nearly all affected operations have been re-implemented as native code in install4j 7.0.8. As part of this work we have fixed a long-standing issue on macOS: When requesting elevated privileges, the password dialog notified the user that “install4j” wants to make changes.

However, users most likely do not know the name “install4j” and could be tempted to cancel the dialog. Starting with install4j 7.0.8, the full name that is configured in your project is displayed instead:

 

Stricter time-stamp validation on macOS 10.14

Today we released an install4j emergency release for macOS 10.14 that fixes a problem with code signing. Previous versions of install4j used time stamp validation during code-signing in such a way that it’s no longer recognized by macOS 10.14.

Whenever code signatures are invalid, macOS does not report any specific errors, but just informs the user that the archive is damaged and suggests to move it to the trash, like this:

If you use install4j for deploying to macOS, you probably do use code-signing, so we highly recommend to update to install4j 7.0.6 to avoid problems for users on macOS 10.14.

As an added benefit, the new release can scale splash screens under fractional HiDPI on Windows, so they no longer appear to be to small.

Migrating to install4j 7

In nearly all cases, migrating to install4j 7 just means opening and saving your project with the install4j 7 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

  • The minimum supported Java version is now Java 7 up from Java 6 for install4j 6. This also means that the old Java 6 Apple JRE is no longer available as a separate type on the Bundled “JRE” step of the macOS media wizard. The launcher runtime still supports Java 6 and you can set the compiler variable sys.ext.forceMinJavaVersion to true in order to allow “1.6” as a minimum version. Note that no classes in the API can be called from Java 6.
  • The “native splash screen” feature for Windows has been removed. This went back to the pre-Java 6 days when Java did not offer splash screen functionality and was missing several important features. If you had this feature selected for one of your launchers, it now uses the regular Java splash screen
  • When a rollback terminates at a rollback barrier, the exit code of an installer application is now 0. To restore the old exit code of 1, you can set the “Exit code” child property of the “Rollback barrier” property to 1
  • In the “Key validation expression” script property of text components, the “keyCode” parameter has been removed. It was always 0 before and did not serve a useful purpose.
  • If you develop your own screens with the API, the methods isShowIndex, hasTitlePanel, hasDefaultInsets and hasDefaultButtons have been removed from the interface com.install4j.api.screens.Screen and so your existing implementation of these methods will no longer be called by install4j. This functionality is now covered by styles which are much more flexible than the previous limited styling capabilities.
  • In the API, methods with Object[] arguments for variable parameter lists have been converted to varargs. This should not cause source or binary incompatibilities but may show warnings in your code if you call such methods.
  • The “Create a quick launch icon” action has been removed with no replacement. The last OS where it had any effect was Windows Vista.
  • If you have not set a maximum Java version, and do not use a bundled JRE, any installed Java 9 JRE will be used. Java 9 has backward compatibility issues that may prevent your application from working unless you explicitly support it. Consider limiting the maximum Java version to “1.8” in that case.
  • If the “Request privileges” action fails, an installation directory in the user home directory is set. To restore the old behavior of keeping the default installation directory deselect the “Fall back to user specific installation directory” property on the “Request privileges” action.
  • With install4j 7, you cannot use the deprecated com.apple.eawt.Application.Application.getApplication().addApplicationListener(...) in the macOS EAWT API anymore, you have to use the new API methods, for example

    Application.getApplication().setQuitHandler((quitEvent, quitResponse) -> {
    quitResponse.cancelQuit();
    // TODO add your code
    });

    for the quit handler.

If you notice anything else, please let us know!

Comparing install4j to other deployment solutions

Samuel Ruggieri from Voyager Games has written an interesting article comparing install4j against Java Web Start and other installer builders. His conclusion is this:

“At the end of this adventure, I have another experience that demonstrates the old adage that it’s cheaper to buy software than to build it. In this case, it’s cheaper and better. Software engineer hours are expensive, and for a non-trivial Java application, you’ll burn scores of them if you try to build a custom deployment and auto-update solution. At the end of that development, whatever you’ve built will almost certainly be inferior to what install4j can give you with a bare minimum of expense, both in terms of time and effort.”

If you’re thinking about comparing different deployment solutions for your Java application, maybe his article can provide some shortcuts.

Migrating to install4j 6

In nearly all cases, migrating to install4j 6 just means opening and saving your project with the install4j 6 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

  • The minimum Java version for launchers is now Java 6. If your launchers must run with Java 1.4 or Java 5, you have to stick with install4j 5.
  • The minimum Java version for the install4j IDE and the compiler is now Java 7. If your build machine only has Java 6 installed, you have to install a Java 7 JRE. On Windows and Mac OS X, Java 7 JREs are bundled in the install4j downloads.
  • The install4j API has been generified and old-style enums have been converted to language enums. Theses changes are binary and source compatible. The only exception is that enums do no longer extend com.install4j.api.SerializableEnum. In the unlikely case that you use this class in your custom code, you will have to replace it with the actual enum class.
  • Installer variables loaded by the “Load response file” action or the -varfile command line parameter are now automatically registered as response file variables. The eliminates problems with fast-path upgrade installations where response file variables would be lost if their form components were not be shown. If this change impacts on your logic, the “Load response file” action now has a “Register variables for response file” property that you can deselect to revert to the old behavior.
  • By default, the “Load response file” action will no longer overwrite installer variables that have been set explicitly on the command line with the -Vvariable=value option. This is the intuitive behavior and makes installer variables more flexible. If this change impacts on your logic, the new “Overwrite strategy” property of the “Load response file” action can be set to “Do not overwrite existing”.
  • Mac OS X archives are now generated in DMG format. This means that the generated media file name will change between install4j 5 and install4j 6 and you have to adjust download links on your web site. If you would like to keep the .tgz format, you can change the corresponding option on the “Installer options” step of the media wizard.
  • Invisible form components are no longer validated. A validation error would leave the user with no clue what to do, so this was really a mistake in previous versions. However, bound installer variables are set during the validation phase and that will no longer happen for invisible components. If you rely on the installer variables to be defined, you should predefine them in the “Installer variables” section of the installer or custom installer application.
  • Several installer variables that were previously only defined on Windows are now defined on multiple platforms. New cross-platform installer variables are “sys.desktopDir” and “sys.docsDir”. The installer variables “sys.appDataDir”, “sys.localAppdataDir”, “sys.docsDir”, “sys.fontsDir” and “sys.programsDir” are now also defined on Mac OS X. If your code checks if any of these installer variables is null, it may no longer work correctly.
  • The “Reboot computer” action and Context#triggerReboot now work on Mac OS X as well. If you rely on the previous behavior of not doing anything on Mac OS X, this may not be what you want. In that case, you have to add platform-specific checks in your project.
  • The ICNS icon for Mac OS X launchers is now generated from cross-platform images. If you previously had no ICNS icon defined but the “Add icon to launcher” check box was selected, the maximum resolution of your icon files might be too low. You need at least a 128×128 image for the icon to look good on Mac OS X. The old default ICNS icon is still available under resource/macos/app.icns, so you can specify it explicitly to restore the old behavior.
  • The name of the uninstaller on Mac OS X has changed if your project is localized. Previously the file name of the uninstaller application bundle was set to the localized name. In install4j 6, the file name is always set in the principle language and the localization is provided by the application bundle. You will see the localized name in the Finder, but not in the terminal.

If you notice anything else, please let us know!

    The v2 signature scheme for application bundles on Mac OS X 10.9.5+

    Apple has decided to introduce a new signing scheme in the upcoming Mac OS X 10.9.5 maintenance release.

    The good news is that the new signature is much better from a security point of view. The utility of the old signature was highly questionable, because it allowed unsigned and modifiable files in the application bundle. An attacker could change the JAR files in the application bundle and the signature of the application bundle would remain valid.

    The bad news is that all existing signatures are going to break. Only applications with a v2 signature will be accepted by Gatekeeper starting with Mac OS X 10.9.5. On the upside, the v2 signature is backwards compatible with older versions of Mac OS X. The means that if your application bundle is signed with the new scheme it will work in Mac OS 10.8, 10.9 and 10.10 – and hopefully even with future versions of Mac OS X.

    We have implemented v2 signatures in install4j 5.1.13, so you can already create application bundles that will work with the upcoming disruptive releases of Mac OS X.

    However, this change may have consequences for your install4j projects:

    • The application bundle that is installed by a “Mac OS X single bundle” installer cannot be signed anymore. The installer installs variable files into the bundle and of course it cannot update the signature of the bundle. Previously all these files did not influence the signature (you can see that this was a bad idea), but now everything in the bundle must be signed. If you really need a signed launcher, you have to switch to the “Mac OS X single bundle” archive.
    •  Info.plist files and .vmoptions files in signed bundles cannot be changed anymore without breaking the signature. If you rely on the validity of the signature of the application bundle, you have to ensure that these files remain untouched. This applies to single bundle and folder archives as well as to the folder installer with signed launchers enabled.

    To make the correct decisions, you have to understand that a signature is only required for the file that user downloads from the internet. An installer can install application bundles that are unsigned, because those will not be checked by Gatekeeper.

    A signature on an installed application bundle is only required if you need access to restricted services, such as iCloud storage or the notification center. In addition, signed application bundles are treated preferentially in some cases. For example, if the user enables the firewall, unsigned application bundles can only receive incoming connections after the user confirms a question from the firewall.

    Migrating to install4j 5.1

    The following new features in the install4j 5.1 require consideration when migrating from 5.0:

    New architecture for elevated privileges

    install4j 5.1 introduces a new architecture for elevated privileges. Under some circumstances this can create backwards compatibility problems with your existing projects that are discussed below.

    Prior to install4j 5.1, the the “Request privileges” action could restart the entire installer process and run the installer GUI and all the actions with elevated privileges. This was the default setting on Windows and also available on Mac OS X. The unelevated process was kept around only for starting launchers and other executables without privileges. On Mac OS X, the default mode for the “Request privileges” action was to start an elevated helper process that was used internally by some actions – such as the service actions. The strategy of running the GUI without elevated privileges is a lot better, but our helper process had very limited capabilities and so it could not be made the default on Windows.

    Enter install4j 5.1: We have now removed the “restart” and beefed up the elevated helper process considerably. Single actions can now be executed in the elevated helper process. To this end, we have added an “Action elevation type” property to all actions in the install4j IDE. Unless the action declares a different default value, it is set to “Inherit from parent”. The “Action elevation type” is also configurable on screens, installer applications, screen groups and action groups, and determines the default value for the contained actions.

    If an action is set to be executed with maximum available privileges and an elevated helper process has been started by the “Request privileges” action, the action is serialized to the elevated helper process, executed there and then serialized back to the unelevated process. In the elevated helper process, it has access to all installer variables and it can interact with the GUI through the methods in the com.install4j.api.Util class. Elevated actions in console installers can use all methods in the provided com.install4j.api.screens.Console object to interact with the user.

    If you are just using standard actions, migrating to install4j 5.1 should not break anything. If you use custom code, the two-process architecture and the changed default privileges might impact your installer. Here are the points that you should look at:

    • Using static state in elevated actions may have unintended consequences, since static state is not synchronized between the two processes. Only use installer variables for saving state.
    • Elevated actions must be serializable. The base interface for actions now extends java.io.Serializable, but all contained objects must be serializable as well, otherwise a fatal error will occur.
    • Installer variable values should be serializable. If you place a non-serializable value into an installer variable, you will not be able to use it in elevated actions.
    • If your action previously assumed that it would have full privileges, you have to set its “Action elevation type” to “Elevate to maximum available privileges” manually. For example, a “Run script” action that modifies a file with your own code may not work on a file in the installation directory unless you elevate the action. For custom actions, you can call setFullPrivilegesRequired or setDefaultActionElevationType in your action bean info in order to automatically set the correct elevation type in the install4j IDE when the action is inserted.
    • Some methods in the API do not work in the elevated helper process. They have been marked to throw NotSupportedInElevationException in the API javadoc. Mainly this concerns methods in the context that change the control flow (i.e. jump to another screen) or methods that modify the GUI. If your action needs to use these methods while at the same time requiring elevation, you can always use context.runElevated(...) to push a piece of code to the elevated helper process.

     The key advantages of the new architecture are:

    • Unified privileges architecture for Windows and Mac OS X
    • No more problems due to user change on authentication
    • Privileges can reasonably be requested at any point in the installer, not only at the beginning
    • Better desktop integration of the installer GUI, for example for drag and drop

    Support for OpenJDK on Mac OS X 

    OpenJDK is the way forward for Java applications on Mac OS X. However, the following points need your attention:

    • It is not possible to deliver an installer or a single bundle archive that support both the old Apple JRE as well as OpenJDK. The stubs are different and you choose either option in the media wizard. Old projects will keep the Apple JRE option, so nothing will change by default
    • JRE bundling on Mac OS X is only supported for Open JDK
    • The minimum Java version for OpenJDK is Java 7 and the minimum Mac OS X version is 10.7.3. So you can currently target only newer systems and only if your application supports Java 7.

    Code signing for Windows and Mac OS X

    Code signing on Windows and Mac OS X is now implemented in pure Java code which works on any supported platform. Previously, install4j only offered a hook for inserting an external code signing tool for Windows which would be executed for each launcher and installer application. This functionality is still available for Windows media files and is now called “Executable processing”. So your existing solution for code signing will still work and there is no immediate need for action.

    However, if you have .pvk and .spc files for your code signing certificate, you can enter them on the General Settings->Code Signing tab and enable Windows code signing there. You then have to remove the external code signing command on the “Executable processing” step of the media wizard.

      Beyond installing

      In the two last articles, I showed how to build an installer with install4j for Sweet Home 3D, then improve it with various options. But a program lives, and more and more users are used to getting program updates automatically. As install4j includes an auto-update feature, I’m going to use it to update Sweet Home 3D when a new version is released. Finally, I’ll provide all the nice options that install4j offers for Mac OS X and Linux users by creating a cross platform installer.

      Auto-updating

      install4j offers various ways to check whether updates are available and to manage the launching of the updater. As I want to provide auto-updating without modifying the Sweet Home 3D source code at this moment, I’m going to set options in install4j that will check if a new version of the program is available when the program is launched. The auto-update feature is informed about the availability of a new version thanks to an updates.xml file I’ll have to host at a specified URL. Each time an installer is built, install4j creates a default updates.xml file in the output directory, and when a new version will be available, I’ll just have to upload that file along with the new version of the installer. For the version 3.0 of the installer, this file looks like this:

      <?xml version="1.0" encoding="UTF-8"?>
      <updateDescriptor baseUrl="">
      <entry targetMediaFileId="80" updatableVersionMin="" updatableVersionMax=""
        fileName="SweetHome3D-3.0-windows.exe" newVersion="3.0" newMediaFileId="80"
        fileSize="27361280" bundledJre="windows-x86-1.6.0_23" archive="false">
      <comment language="en" />
      <comment language="zh_CN" />
      <comment language="cs" />
      <comment language="fr" />
      <comment language="de" />
      <comment language="el" />
      <comment language="hu" />
      <comment language="it" />
      <comment language="ja" />
      <comment language="pl" />
      <comment language="pt_BR" />
      <comment language="ru" />
      <comment language="es" />
      <comment language="sv" />
      </entry>
      </updateDescriptor>

      To prepare future updates, I have to decide in this version where I’ll host the updates.xml file. Thus, I enter the URL “ http://www.sweethome3d.com/download/updates.xml ” in Auto-Update Options tab of the Installer screen.

      Then, in the Screens & Actions tab, I click on the Insert button and select the Add Application menu item.

      In the Select an Application Template dialog box, I select the Updater with silent version check template.

      Once I click on OK, a new node is added to Installer screen for the updater application and I name its Executable as “ SweetHome3DUpdater ” in its Properties tab.

      To run this updater automatically when Sweet Home 3D or Furniture Library Editor are launched, I click on the Launcher Integration tab, select the Start automatically when launcher is executed option and choose to Always run the updater.

      Minimum auto-updating is now integrated and I just have to build a new installer to make it available for a future version of the program.

      To test it, I immediately install version 3.0 of the program, generate an installer with a fake 3.0.1 higher version number,

      and upload SweetHome3D-3.0.1-windows.exe and updates.xml to http://www.sweethome3d.com/download after adding a small comment in default language to updates.xml file.

      <?xml version="1.0" encoding="UTF-8"?>
      <updateDescriptor baseUrl="">
      <entry targetMediaFileId="80" updatableVersionMin="" updatableVersionMax=""
        fileName="SweetHome3D-3.0.1-windows.exe" newVersion="3.0.1" newMediaFileId="80"
        fileSize="27427328" bundledJre="windows-x86-1.6.0_23" archive="false">
      <comment>Fixed minor bugs</comment/>
      </entry>
      </updateDescriptor>

      Then, a few seconds after I launch Sweet Home 3D version 3.0, the updater is launched and offers to download Sweet Home 3D version 3.0.1.

      If I click on the Show comments link, I get the comments entered in the updates.xml file.

      Otherwise the download of the new version is started.

      Once downloaded, I choose to execute the downloaded installer.

      Because the installer detects that a previous version is installed on my computer, it asks me whether to update or to install it in another location before performing the installation.

      Managing cross platform installers

      Since install4j is a Java program itself, it’s easy to prepare installers for each operating system where JVMs are available. If an application shares the same list of files (which is generally the case), I would just have to create a different media for each targeted operating system with its dedicated JRE. It’s a little more complicated for Sweet Home 3D since it requires different Java 3D DLLs for different platforms. Therefore, I download Java 3D zip binaries for Mac OS X, Linux 32 bits and Linux 64 bits at Java 3D release builds page. Each of these zipped files contains a j3d-jre.zip file, and each j3d-jre.zip file contains the three j3dcore.jar, vectmath.jar and j3dutils.jar files which are the same as the Windows ones I have already, plus some DLLs like libj3dcore-ogl.so under Linux that I have to keep. Under Mac OS X, Java 3D works thanks to JOGL library, that I download too.
      Once I retrieve all these files, I copy the ones required by Java 3D in a lib subdirectory of Install directory and reorganize them to avoid any name conflict.

      These files will have to be copied in the lib subdirectory of the destination directory where program will be installed. To copy only the Java 3D files required for a given operating system, I’m going to create one file set for each system in install4j. In the Files screen, I click first on the Insert button and choose the New File Set option.

      I enter the general name “ Windows “,

      and renew the New File Set operation for Mac OS X, Linux 32 bits and Linux 64 bits.

      Then, for each of these file sets, I create a new lib folder by clicking on the Insert button and choosing the New Folder option.

      Once the lib subdirectories are ready, I select the one in Windows file set, click on the Insert button and choose Add Files and Directories option.

      In the Add Files and Directories dialog box, I choose the Single files option,

      click on the Next button, and select the four Java 3D DLLs for Windows in C:Program Files (x86)Sweet Home 3D 3.0lib directory.

      I confirm my choice, and repeat the same operation to add the Java 3D files that depends on Mac OS X, Linux 32 bits and Linux 64 bits.

      To get consistent file sets, I also have to remove the Java 3D DLLs from Default file set: I select the Content of C:Program Files (x86)Sweet Home 3D 3.0lib into subdirectory lib node, click on the Edit Entry button,

      and in the Modify Entry in the Distribution Tree dialog box, I change the entry type to Single files and select all the files in C:Program Files (x86)Sweet Home 3D 3.0lib directory except the four DLLs.

      Once I chose these JAR files, I move them to the lib subdirectory of the installation directory.

      Finally, I click on the Installation Components tab, select the Sweet Home 3D component and include Windows, Mac OS X, Linux 32 bits and Linux 64 bits file sets.

      Now that file sets are ready, I’m going to use them in the Windows existing media file and in the new media files for Mac OS X and Linux. I go to the Media screen,

      and double-click on the Windows media file to exclude the file sets that are not needed for Windows.

      Then, I click on New media file icon to create Linux 32 bits media file. In the Installer type combo box, I choose Unix/Linux GUI installer,

      and click on the Next button until the Data files step where I enter the same download URL http://ovh.dl.sourceforge.net/project/sweethome3d/FurnitureLibraryEditor/ for the Furniture Library Editor as I did for Windows media.

      In the Bundled JRE step, I click on the Download JREs button,

      to download Linux (x86) 1.6.0_23 JRE.

      Once downloaded, I choose this JRE,

      customize the installer by setting the media file name to “ ${compiler:sys.shortName}-${compiler:sys.version}-linux-32bits

      and by excluding the file sets of the other operating systems.

      Once the Media wizard is finished for Linux 32 bits, I create similarly the media file for Linux 64 bits, and rename them as Linux 32 bits and Linux 64 bits with the Rename Media File menu item available in their contextual menu, to be able to distinguish more easily.

      Mac OS X installer is very similar to the other installers except it doesn’t need to download a JRE and it requires an additional VM option to run: as Mac OS X provides its own JRE with the Java 3D 1.3.1 library in extension directory, I have to change the java.ext.dirs system property to ensure the Java 3D 1.5.2 library installed with Sweet Home 3D will have a higher priority. To set this VM option that should replace the -Djava.library.path=lib existing one, I create the java3dDllsVMOption compiler variable by clicking on the Insert button in the Compiler Variables tab of the General Settings screen and enter “ -Djava.library.path=lib ” as its default value.

      Then in the Java invocation step of SweetHome3D launcher, I update the text of the VM Parameters field with ${compiler:java3dDllsVMOption}.

      Finally, I click on New media file icon, choose Mac OS X folder Installer type,

      update the download URL, exclude the file sets of the other operating systems and in Compiler variables step, override java3dDllsVMOption variable with the value
      -Djava.ext.dirs=lib:/Library/Java/Extensions:/System/Library/Java/Extensions:
      /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/ext

      I can now build the 4 installers and test them on each operating system.

       

       

       

      Conclusion

      install4j offers many options to help with auto-updating installed software and to deliver Java cross platform installers and uninstallers. install4j can create installers for all supported platforms on any supported platform, so on a Linux build server you can create installers for Windows and Mac OS X as well.