<appname>

The name of the application that will be installed.

<appversion>

The version of the application

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

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

<authors>

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.

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

As of IzPack 5.2 the value 10 or higher is supported, too.

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

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

<summarylogfilepath>

If this element is present, it specifies the path for the logfile of the `SummaryLoggerInstallerListener`. If it is not specified it defaults to $INSTALL_PATH/Uninstaller/InstallSummary.htm.

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>

<pack200/>

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

1. 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.
2. 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.
3. 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.

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

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

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

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