We need you!

Icon

The IzPack documentation needs work, and you are invited to edit it!

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Header - <info>

The <info> element is used to specify some general information for the installer. It contains the following elements :

Element

Usage

Required

<appname>

The application namename of the application that will be installed.

Yes

<appversion>

The version of the application version

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

No

<authors>

Specifies the author(s) of the application. It must contain at least one <author> element; see below.

Yes

<author>

Child of authors. Has the attributes

  • name the author's name
  • email the author's email
at least 1
 <uninstaller>

specifies whether to create an uninstaller after installation, and which name to use for it. This tag has the attributes:

  • write
attribute, with
  • (optional, values "yes" or "no", default value "yes". If
this tag is not specified
  • yes, the uninstaller will
still
  • be written.
The name attribute
  • name (optional, no default) It can be used to change the default name of the generated uninstaller, i.e. uninstaller.jar.
The condition attribute
  • condition (optional, no default) This can be used to specify a condition which has to be
fullfilled
  • fulfilled for creating the uninstaller.
The path attribute
  • path (optional, defaults to  ${INSTALL_PATH}  This can be used to define the destination path where the uninstaller is written to, i.e. ${INSTALL_PATH}/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.

Yes

<requiresjdk>

Valid values: yes or no. Specifies wether 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 still proceed with the installation process or notabort.

Yes

<webdir>

Causes If this element is present, a web installer to will be created, and . The contents of the tag specifies the URL from which packages are retrieved from at install time. The content of the tag element must be a properly formed URL that points to the remote folder where the packages reside.

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

<writeinstallationinformation>

Valid values : are yes or no. Default is yes. Sspecifies Specifies if the file .installinformation should be written which . This file includes the information about installed packs.

No

<pack200/>

adding 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. This Compressing makes the compilation process a little bit longer, but it usually results in drasticaly 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).

 

<tempdir/>

if 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 that installer around those artifacts to be kept afterwards. You can do this with the delete attribute on the execute tag element but that won't clean up any supporting files.
  2. If you have some sql 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
  • 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 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. You can disable this feature for the uninstaller by specifying uninstaller="yes" as an attributeattribute. Only use this feature if you really need to be an administrator as part of your installation process.

No

<rebootaction>

defines Defines what to do if there were pending file installation operations left which require a reboot; otherwise any of 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 (no 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.

...

The usage of <rebootaction> is

...

requires the use of the attribute blockable with the values auto or force at least in one of the elements <file>, <singlefile> or <fileset>,

...

which indicates blocked files

...

which would result in a failing installation of the file

...

if izPack tries to write these files during the installation. See the documentation of these elements later.
<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 limit reboot processing on particular conditions.
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 section.

...

No

Notes:

Here is an example of a typical <info> section :

...