|
The child nodes of a file set are called installation roots.
Their location is resolved when the installer runs. There are two types of roots:
-
The default root of the distribution tree is labeled as "Installation directory" and
has a special icon. This
is the directory where your application will be installed on the target system. The directory
is dependent on user actions at the time of installation. In regular installers
a user can select an arbitrary directory where the application should be installed. For RPM
media files, a user can override the default directory with command line parameters. For
archives, the files are simply extracted into a commmon top-level directory.
The installation directory will only be created if you execute an "Install files" action
in the installer configuration. By default, the
"Install files" action is placed on the "Installation" screen. If your installer should not create
an installation directory, you can ignore this root and remove the "Install files" action.
To learn more on the various installer modes, please see the corresponding
help topic.
-
If your application needs to install files into directories outside the main installation directory,
you can add custom roots to the distribution tree. This is done with the
New Root action
in the add menu on the right side or in the context menu.
The actual location of this root is defined by its name and has to resolve to a valid directory at runtime.
There are several possibilities for using custom roots. The name of a custom root can be
- a fixed absolute path known at compile-time
This works for custom environments where there's a fixed policy for certain locations. For example,
if you have to install some files to D:\apps\myapp , you can enter that path as the name
for your custom root.
If you build installers for different platforms, that root is likely to be different for each platform.
In that case, you can use a compiler variable
for the name of the custom root and
override its value for each media file.
- an installer variable that you resolve at runtime
If you would like to install files into the directory of an already installed application, such as a
plugin for your own application, you can use an installer variable that you resolve at runtime.
Installer variables have an installer: prefix, such as ${installer:rootDir} ,
and can be set in a variety of ways.
The most common case would be to add a
"Directory selection" screen to the screen sequence
and set its variable name property to the variable that you've used as the name of the custom root.
For the above example, that would be "rootDir" (without the ${installer:...} variable syntax).
Alternatively, you could use a "Set a variable" action to determine the location programmatically.
- a pre-defined installer variable
install4j offers several variables for "magic folders" that point to common directories, such as
${installer:sys.userHome} which resolves to the user home directory or
${installer:sys.system32Dir} which resolves to the system32 directory on
Windows.
If a custom installation root is not bound at runtime or if it points to an invalid directory,
the contained files will not be installed. There will be no error messages, if you require error
handling, you can use a "Run a script" action before the "Install files" action with the
appropriate error message and failure strategy.
Note: For archive media file types, custom
installation roots are not installed. If you require these custom roots for your installation, you
cannot use archives.
An alternative way to redirect installed files to different directories is to use the
"Directory resolver" property of the "Install files" actions. Also, the "File filter" property
of that action can be used to conditionally install files. The use of these properties is only
recommended if you require their full flexibility. Otherwise, using custom installation roots and
installation components is a better approach.
|