Element | Usage | Required |
|---|
<appname>
| The name of the application that will be installed. | Yes |
<appversion>
| The version of the application | Yes |
<appsubpath>
| The subpath for the default of the installation path. This will be appended to the installation folder selected by the user and will be created during the installation if it does not exist. A variable substitution will be done at compile time and a maskable slash-backslash conversion will be done at run-time. If this tag is not defined, the application name will be used instead. | No |
<url>
| The URL of the application's official website. Note: You can add the project URL from the Maven POM file by setting the configuration option <autoIncludeUrl>true</autoIncludeUrl> of the izpack-maven-plugin, see the IzPack Maven Plugin Reference. | No |
<authors>
| Specifies the author(s) of the application. It must contain at least one <author> element; see below. Nested elements: <author> with the following attributes: Attribute Name
of <author> | Description |
|---|
| name | the author's name | email | the author's email address |
Example: | Code Block |
|---|
| <authors>
<author name="Bud Spencer" email="buddy@buggy.com"/>
</authors> |
Note: You can add authors listed in the Maven POM file by setting the configuration option <autoIncludeDevelopers>true</autoIncludeDevelopers> of the izpack-maven-plugin, see the IzPack Maven Plugin Reference. | Yes |
<uninstaller> | specifies whether to create an uninstaller after installation, and which name to use for it. This tag has the attributes: - write (optional, values "
yes", "no", "true", "false"; default value "yes")
If yes, the uninstaller will be written. - path (optional, defaults to "
$INSTALL_PATH/Uninstaller")
Specifies the destination path where the uninstaller jar file is written to during the installation. - name (optional, default: "
uninstaller.jar")
Specifies the default name of the uninstaller jar generated during the installation. - condition (optional, no default)
Specifies a condition which has to be fulfilled for creating the uninstaller.
| No |
<javaversion>
| This specifies the minimum version of Java required to install your program. Values can be 1.2, 1.2.2, 1.4, etc. The test is a lexical comparison against the java.version System property on the install machine. This tag has attribute: - strict (optional, values "
yes", "no", "true", "false"; default value "false")
If yes, the minimal java target class version will compared with the set version and compiler will fail if the target class version is not equal or lower than than the set one. If set to false, only warnings will be thrown.
| Yes |
<requiresjdk>
| Valid values: yes or no. Specifies whether a JDK is required for the software to be installed and executed. If "yes" and the JDK is not already installed, then the user will be informed and given the option to proceed with the installation process or abort. | Yes |
<webdir>
| If this element is present, a web installer will be created. The contents of the tag specifies the URL from which packages are retrieved at install time. The content of the element must be a properly formed URL that points to the remote folder where the packages reside. See Web Installers for more information. | No |
<summarylogfilepath>
| If this element is present, it specifies the path for the logfile of the `SummaryLoggerInstallerListener`. If it is not specified the logfile is not created. | No |
<readinstallationinformation> |
Specifies whether the file .installationinformation should be read. This is useful to prevent breaking updates to files installed with older versions of IzPack which wrote .installationinformation by setting <writeinstallationinformation>true</writeinstallationinformation> but the contents of this file are no longer compatible to the updated version. The file .installationinformation contains serialized binary objects and is potentially binary incompatible with each new IzPack version. Valid values are yes, no, true, false. Default is yes. See InstallationTypePanel and TreePacksPanel to see how this information can be handled by the installer. |
|
<writeinstallationinformation>
| Specifies whether the file .installationinformation should be written. This file includes a list of installed packs and variables set when running an installer.. If true, at the end of the installation a binary file $INSTALL_PATH/.installationinformation is written with a serialized list of installed packs and variables. If there is an IzPack variable modify.izpack.install set to "true", and the installer is run (even in a later version) in the same installation directory the following happens: - The list of packs is read again. To make effective use of this it is necessary to use the TreePacksPanel. After passing the TargetPanel and reading the preinstalled packs from $INSTALL_PATH, TreePacksPanel offers only those packs which haven't already been installed and marks the preinstalled packs as partially selected. Partially selected packs can be reinstalled or removed. The additional packs selected in the second run will then be added to the list of packs which is written to
.installationinformation at the end of the (update) installation run. - The set of variables is read and overrides existing variables with the same name for the current installer run.
This can be useful for simple installers to simplify updating over a previous installation. Valid values are yes, no, true, false. Default is yes. See InstallationTypePanel and TreePacksPanel to see how this information can be handled by the installer. | Warning |
|---|
The information is very fragile and every change in packs or variables can break the update functionality of an installer for a dedicated information. Just a basic merging is done for packs and overridden variables can lead to unexpected behavior. It is not recommended to use this feature for more complex installers.
The .installinformation file depends on Java serialization which might change between JRE and IzPack versions. |
| No |
<pack200/>
| Adding this element will cause every JAR file that you will add to your packs to be compressed using Pack200. As a special exception, signed JARs are not compressed using Pack200, as it would invalidate the signatures. Compressing makes the compilation process a little bit longer, but it usually results in drastically smaller installer files. The decompression is relatively fast. Please note that Pack200 compression is destructive, i.e., after decompression a JAR won't be identical to its original version (yet the code in the class files remains semantically equivalent).
This flag does not affect the compression of jar files added by the <jar> tag.
| Info |
|---|
As of IzPack 5.1, this tag moved to the level od of pack files, in particular as nested element to the <fileset>, <file> and <singlefile>. |
|
|
<tempdir/>
| If this element is included then a randomly named temporary directory will be created at the start of the install and deleted when the installation completes.
This feature is useful in a couple of scenarios. - If your installer needs to install a third party product or library by executing that products installer, but you don't want those artifacts to be kept afterwards. You can do this with the delete attribute on the execute element but that won't clean up any supporting files.
- If you have some SQL scripts or any other files which need to be run through an interpreter and you don't want them hanging around after the install completes.
- If you need to create a file, populate it with values from the installers gui and pass that file off to another program for some reason, after which you no longer need the file.
A temporary directory allows all of the temporary files created during installation to be kept together and neatly cleaned up automatically at the end of the install, and does so in an OS independent manner.
The following XML attributes are supported:
- variablename: The name of the variable which will contain the absolute path of the temporary directory at runtime. The default value is TEMP_DIRECTORY.
- prefix: A string which will be used as the start of the randomly generated direcotry name. The default value is IzPack.
- suffix: A string which will be used as the end of the randomly generated direcotry name. The default value is Install.
Multiple tempdir elements are supported with unique variablename attributes.
| No |
<run-privileged/>
| Adding this element will make the installer attempt to launch itself with administrator permissions. It also supports a condition attribute to refer to a condition ID so that the elevation is not always attempted (e.g., you may want to activate it only for Windows Vista). This is not supported on all platforms, in which case a message will be provided to the user before continuing the installation. Only use this feature if you really need to be an administrator as part of your installation process. uninstaller="yes" Setting this attribute to "yes" enables this feature for the uninstaller. If set to "no" or omitted, the uninstaller is run without administrator permission.condition This lists the operating systems where the installer should run with administrator permission. The operating systems are specified as literal names separated by the "|"(pipe) character. See the full list of valid conditions.
An example for a windows installer would be <run-privileged condition="izpack.windowsinstall.7|izpack.windowsinstall.vista"/> which would acquire administrator permissions for installers running on Windows 7 or Vista. | No |
<rebootaction>
| Defines what to do if there are pending installation operations left which require a reboot; If there are no pending operations, the options below will be ignored. Possible values are: ignore (default) Doesn't reboot at all even if there are pending operations. Pending operations can be recognized only on the installer command line output (for all options).notice Doesn't reboot, but notifies the user interactively at the end of an installation, which must be confirmed. Notification works only for interactive installation types (not auto-installation).ask Reboots only if the user confirms interactively at the end of an installation.always Reboots always without any confirmation at the end of an installation.
<rebootaction> only works and makes sense on Windows, where target files (as device drivers, EXE or DLL files) might be blocked during an installation. On platforms other than Windows the <rebootaction> element will be ignored.
<rebootaction> supports the condition attribute to allow conditional triggering of reboot processing.
The use of <rebootaction> requires the use of the attribute blockable in at least one of the elements <file>, <fileset> or <singlefile>. This indicates which files would result in a failing installation if izPack tries to write these files during the installation.
Without setting at least one attribute blockable="auto" or blockable="force", <rebootaction> will not have any effect.
See also the description of the blockable attribute in the documentation of the <pack> elements <file>, <fileset> and <singlefile>. | No |
<singleinstance> | By default, IzPack will pop up a message which asks the user whether an already running instance of the same installer should be ignored or rather whether to abort the new instance. This can be inconvenient for some use cases (clustering, sub-calls when an installer calls itself with different options,...). You can disable this behavior by setting this option to "no".
Valid values are yes or no. Default is yes.
Since: IzPack 5.0 RC5 | No |
| If this element is included and specifies a valid date formatted as "YYYY-MM-DD", the installer will display a brief message and exit if started on or after the specified date. If <expiresdate> is not specified, the installer will not expire. If <expiresdate> is specified incorrectly, installation compilation will fail with a relevant message. | Code Block |
|---|
| <expiresdate>2016-06-29</expiresdate> |
Since: IzPack 5.0 RC5 | No |
<pack-compression-format> | Pack compression of standard compression formats different to Pack200 can be enabled globally either at compiler level, like a Maven plugin or Ant option, or in the <info> section. Only the raw data of the files packed to the installer is compressed using this method during compiling and automatically uncompressed by the installer. The following formats are supported: - GZIP ('gz')
- BZIP2 ('bzip2')
- XZ ('xz') (very good compression rate, but slower)
- LZMA ('lzma') (very good compression rate, but slower)
- Deflate/ZIP ('deflate')
The default is adding all files uncompressed to the installer jar, where just the native compression of the installer jar itself applies. Only when enabling one of the above alternative compression formats, there is automatically added the Apache commons-compress code to the installer for handling it. See also Compressing pack files. Since: IzPack 5.1.0 | No |