...
Attribute | Description | Required | Values | |
---|---|---|---|---|
| the file location (relative path) - if this is a directory its content will be added recursively. It may contain previously defined static variables (see | yes |
| |
| the destination directory, could be something like | yes |
| |
| Limit installation of this particular file only to the given target OS type. | no | "unix" | "windows" | "mac" | |
| Whether to overwrite existing files. | no | "true" | "false" | "asktrue" | "askfalse" | "update" | |
overrideRenameTo | Globmapper to rename a conflicting file to. This works similar like the <globmapper> in File Name Mappers, whereby the mapper's from attribute is set to "" and the to attribute exactly to the value given here. Example ".bak" will rename the target file by appending the suffix .bak before overwriting it. The override attribute must be set "true" to activate this feature. | no | String - valid globmapper target expression | |
blockable | For Windows only, ignored on non-Windows systems: | no | | |
| if true and the file is an archive then its content will be unpacked and added as individual files | no | "true" | "false" | |
| Limit installation of this particular file to the given condition, which must be true during the file installation. | no | String - a valid condition ID | |
casesensitive | Whether to treat the file name case-sensitive. | no | "true" | "false" | |
defaultExcludes | Whether to use global default excludes. | no | "true" | "false" | |
followSymLinks | Whether to follow symbolic links on target systems which support them. | no | "true" | "false" | |
Implicit default exclude patterns are typically:
Since IzPack 5.0 | no | "true" | "false" | ||
followSymLinks | Whether to follow symbolic links on target systems which support them. | no | "true" | "false" |
Nested Elements
The following nested elements can be used in the <file> tag:
- <os>
Limit the installation of this file to conditions depending on the target OS, see below.
<additionaldata>
This tag can also be specified in order to pass additional data related to a file tag for customizing.
| key to identify the data |
| value which can be used by a custom action |
<singlefile>
- add a single file
...
<singlefile>
- add a single file
Specifies a single file to include. The difference to <file>
is that this tag allows the file to be renamed, therefore it has a target attribute instead of targetdir
.
...
Attributes
...
Attribute | Description | Required | Values |
---|---|---|---|
| the file location (relative path). It may contain previously defined static variables (see | yes |
|
| the destination file name, could be something like | yes |
|
| can optionally specify a target operating system (unix, windows, mac) - this means that the file will only be installed on its target operating system | ||
| see | ||
| an id of a condition which has to be fullfilled to install this file |
An <additionaldata>
tag can also be specified for customizing.
<fileset>
- add a fileset
The <fileset>
tag allows files to be specified using the powerful Jakarta Ant set syntax. It takes the following parameters:
| the base directory for the fileset (relative path) |
| the destination path, works like for |
| optionally lets you specify if the names are case- sensitive or not - takes yes or no |
| optionally lets you specify if the default excludes will be used - takes yes or no. |
| specifies the operating system, works like for |
| see |
| comma- or space-separated list of patterns of files that must be included; all files are included when omitted. This is an alternative for multiple include tags. |
| comma- or space-separated list of patterns of files that must be excluded; no files (except default excludes) are excluded when omitted. This is an alternative for multiple exclude tags. |
| an id of a condition which has to be fullfilled to install the files in this fileset |
You specify the files with <include> and <exclude> tags that take the name parameter to specify the Ant-like pattern :
**
: means any subdirectory
*
: used as a wildcard.
Here are some examples of Ant patterns :
| will include lib and the subdirectories of lib |
| will exclude any file in any directory starting from the base path ending by .java |
| will include all the files ending by .jar in lib |
| will exclude any file in any subdirectory starting from lib whose name contains FOO. |
There is a set of definitions that are excluded by default file-sets, just as in Ant. IzPack defaults to the Ant list of default excludes. There is currently no equivalent to the <defaultexcludes>
task. Default excludes are:
Code Block |
---|
**/*\~{}
**/\#*\#
**/.\#*
**/%*%
**/.\_*
**/CVS
**/CVS/**
**/.cvsignore
**/SCCS
**/SCCS/**
**/vssver.scc
**/.svn
**/.svn/**
**/.DS\_Store
|
An <additionaldata>
tag can also be specified for customizing.
<parsable>
- parse a file after installation
Files specified by <parsable>
are parsed after installation and may have variables substituted.
| the file to parse, could be something like |
| specifies the type (same as for the resources) - the default is plain |
| specifies the file encoding |
| specifies the operating system, works like for |
| an id of a condition which has to be fullfilled to parse this file |
<executable>
- mark file as executable and optionally execute it
The <executable>
tag is a very useful thing if you need to execute something during the installation process. It can also be used to set the executable flag on Unix-like systems. Here are the attributes:
| the file to run, could be something like |
| If the executable is a jar file, this is the class to run for a Java program |
| |
| specifies when to launch :
|
| specifies what to do when an error occurs:
|
| specifies the operating system, works like for |
| takes |
| an id of a condition which has to be fullfilled to execute this file |
Takes an <args>
tag to pass one or more arguments (one <arg>
tag per argument) to the executable.
<arg>
passes the argument specified in the value
attribute. Slashes are handled special (see attribute targetfile of tag <parsable>
.
...
<os>
- make a file OS-dependent
The <os>
tag can be used inside the <file>
, <fileset>
, <singlefile>
, <parsable>
, <executable>
tags to restrict it's effect to a specific operating system family, architecture or version using the following attributes:
| unix, windows, mac to specify the operating system family |
| the operating system name |
| the operating system version |
| the operating system architecture (for instance the Linux kernel can run on i386, sparc, and so on) |
Example
...
<packs>
(...)
<pack name="Core" required="yes">
(...)
<executable targetfile="$INSTALL_PATH/bin/compile" stage="never">
<os family="unix"/>
</executable>
(...)
</pack>
(...)
</packs>
<refpack>
The <refpack>
takes only one attribute file
, which contains the relative path (from the installation compiler) to an externally defined packs-definition. This external packs definition is a regular IzPack installation XML. However the only elements that are used from that XML file are the <packs> and the <resources> elements.
This enables a model in which a single developer is responsible for maintaining the packs and resources (e.g. separate packsLang.xml_xyz files providing internationalization; see Internationalization of the PacksPanel) related to the development-package assigned to him. The main install XML references these xml-files to avoid synchronization efforts between the central installation XML and the developer-maintained installer XMLs.
Attributes
Attribute | Description |
---|---|
| Relative path during compile-time to an externally defined packs-definition |
<refpackset>
The <refpackset>
tag can be used in situations were there is no predefined set of <refpack>
files, but a given directory should be scanned for <refpack>
files to be included instead. This element takes the following parameters:
Attribute | Description |
---|---|
| Relative base directory during compile-time for the refpackset |
| Pattern of files in |
Example:
Code Block |
---|
<refpackset dir="" includes="**/refpack.xml" /> |
Internationalization of the PacksPanel
In order to provide internationalization for the PacksPanel, so that your users can be presented with a different name and description for each language you support, you have to create a file named packsLang.xml_xyz where xyz is the ISO3 code of the language in lowercase. Please be aware that case is significant. This file has to be inserted in the resources section of `` install.xml`` with the id and src attributes set at the name of the file. The format of these files is identical with the distribution langpack files located at `` $IZPACK_HOME/bin/langpacks/installer``. For the name of the panel you just use the pack id as the txt id. For the description you use the pack id suffixed with .description.
An example:
...
<resources>
<res id="packsLang.xml_eng" src="i18n/myPacksLang.xml_eng"/>
</resources>
The packsLang.xml_eng file:
...
no | "unix" | "windows" | "mac" | ||
| Whether to overwrite existing files. | no | "true" | "false" | "asktrue" | "askfalse" | "update" |
overrideRenameTo | Globmapper to rename a conflicting file to. This works similar like the <globmapper> in File Name Mappers, whereby the mapper's from attribute is set to "" and the to attribute exactly to the value given here. Example ".bak" will rename the target file by appending the suffix .bak before overwriting it. The override attribute must be set "true" to activate this feature. | no | String - valid globmapper target expression |
blockable | For Windows only, ignored on non-Windows systems: | no | |
| an id of a condition which has to be fullfilled to install this file |
...
Nested Elements
...
The following nested elements can be used in the <singlefile> tag:
- <os>
Limit the installation of this file to conditions depending on the target OS, see below. <additionaldata>
Add customizing data, see below.
<fileset>
- add a fileset
The <fileset>
tag allows files to be specified similar like in Apache Ant.
...
Attributes
...
Attribute | Description | Required | Values | ||
---|---|---|---|---|---|
| the base directory for the fileset (relative path) | yes |
| ||
| the destination path, works like for | yes |
| ||
| optionally lets you specify if the names are case- sensitive or not - takes yes or no | no |
| ||
defaultExcludes | Whether to use global default excludes.
Since IzPack 5.0 | no | "true" | "false" | ||
| specifies the operating system, works like for | no | "unix" | "windows" | "mac" | ||
| Whether to overwrite existing files. | no | "true" | "false" | "asktrue" | "askfalse" | "update" | ||
overrideRenameTo | Globmapper to rename a conflicting file to. This works similar like the <globmapper> in File Name Mappers, whereby the mapper's from attribute is set to "" and the to attribute exactly to the value given here. Example ".bak" will rename the target file by appending the suffix .bak before overwriting it. The override attribute must be set "true" to activate this feature. | no | String - valid globmapper target expression | ||
blockable | For Windows only, ignored on non-Windows systems: | no | | ||
| comma- or space-separated list of patterns of files that must be included; all files are included when omitted. This is an alternative for multiple include tags. |
|
| ||
| comma- or space-separated list of patterns of files that must be excluded; no files (except default excludes) are excluded when omitted. This is an alternative for multiple exclude tags. |
|
| ||
| an id of a condition which has to be fulfilled to install the files in this fileset |
|
|
...
Nested Elements
...
The following nested elements can be used in the <singlefile> tag:
- <os>
Limit the installation of this file to conditions depending on the target OS, see below. <additionaldata>
Add customizing data, see below.- <include>
Explicitely include files by pattern, similar like Ant fileset patterns. For more information see the FileSet core type. - <exclude>
Explicitely exclude files by pattern, similar like Ant fileset patterns. For more information see the FileSet core type.
<parsable>
- parse a file after installation
Files specified by <parsable>
are parsed after installation and may have variables substituted.
| the file to parse, could be something like |
| specifies the type (same as for the resources) - the default is plain |
| specifies the file encoding |
| specifies the operating system, works like for |
| an id of a condition which has to be fullfilled to parse this file |
<executable>
- mark file as executable and optionally execute it
The <executable>
tag is a very useful thing if you need to execute something during the installation process. It can also be used to set the executable flag on Unix-like systems. Here are the attributes:
| the file to run, could be something like |
| If the executable is a jar file, this is the class to run for a Java program |
| |
| specifies when to launch :
|
| specifies what to do when an error occurs:
|
| specifies the operating system, works like for |
| takes |
| an id of a condition which has to be fullfilled to execute this file |
Takes an <args>
tag to pass one or more arguments (one <arg>
tag per argument) to the executable.
<arg>
passes the argument specified in the value
attribute. Slashes are handled special (see attribute targetfile of tag <parsable>
.
Anchor | ||||
---|---|---|---|---|
|
<os>
- make a file OS-dependent
The <os>
tag can be used inside the <file>
, <fileset>
, <singlefile>
, <parsable>
, <executable>
tags to restrict it's effect to a specific operating system family, architecture or version using the following attributes:
Attribute | Description |
---|---|
| unix, windows, mac to specify the operating system family |
| the operating system name |
| the operating system version |
| the operating system architecture (for instance the Linux kernel can run on i386, sparc, and so on) |
Example
Code Block | ||||
---|---|---|---|---|
| ||||
<packs>
(...)
<pack name="Core" required="yes">
(...)
<executable targetfile="$INSTALL_PATH/bin/compile" stage="never">
<os family="unix"/>
</executable>
(...)
</pack>
(...)
</packs>
|
<additionaldata>
- Adding Customizing Data
This tag can also be specified in order to pass additional data related to a file tag for customizing.
Attribute | Description |
---|---|
| key to identify the data |
| value which can be used by a custom action |
<refpack>
The <refpack>
takes only one attribute file
, which contains the relative path (from the installation compiler) to an externally defined packs-definition. This external packs definition is a regular IzPack installation XML. However the only elements that are used from that XML file are the <packs> and the <resources> elements.
This enables a model in which a single developer is responsible for maintaining the packs and resources (e.g. separate packsLang.xml_xyz files providing internationalization; see Internationalization of the PacksPanel) related to the development-package assigned to him. The main install XML references these xml-files to avoid synchronization efforts between the central installation XML and the developer-maintained installer XMLs.
Attributes
Attribute | Description |
---|---|
| Relative path during compile-time to an externally defined packs-definition |
<refpackset>
The <refpackset>
tag can be used in situations were there is no predefined set of <refpack>
files, but a given directory should be scanned for <refpack>
files to be included instead. This element takes the following parameters:
Attribute | Description |
---|---|
| Relative base directory during compile-time for the refpackset |
| Pattern of files in |
Example:
Code Block |
---|
<refpackset dir="" includes="**/refpack.xml" /> |
Internationalization of the PacksPanel
In order to provide internationalization for the PacksPanel, so that your users can be presented with a different name and description for each language you support, you have to create a file named packsLang.xml_xyz where xyz is the ISO3 code of the language in lowercase. Please be aware that case is significant. This file has to be inserted in the resources section of `` install.xml`` with the id and src attributes set at the name of the file. The format of these files is identical with the distribution langpack files located at `` $IZPACK_HOME/bin/langpacks/installer``. For the name of the panel you just use the pack id as the txt id. For the description you use the pack id suffixed with .description.
An example:
Code Block | ||||
---|---|---|---|---|
| ||||
<resources>
<res id="packsLang.xml_eng" src="i18n/myPacksLang.xml_eng"/>
</resources>
|
The packsLang.xml_eng file:
Code Block | ||||
---|---|---|---|---|
| ||||
<langpack>
<str id="myApplication" txt="Main Application"/>
<str id="myApplication.description" txt="A description of my main application"/>
[...]
</langpack>
|
| override
| Whether to overwrite existing files.
Use asktrue
or askfalse
if the user should be interactively asked what to do and supply default value for non-interactive use. Another possible value is update. It means that the new file is only installed if it's modification time is newer than the modification time of the already existing file (note that this is not a reliable mechanism for updates - you cannot detect whether a file was altered after installation this way.) | no
| "true" | "false" | "asktrue" | "askfalse" | "update"
("update")
|
overrideRenameTo | Globmapper to rename a conflicting file to. This works similar like the <globmapper> in File Name Mappers, whereby the mapper's from attribute is set to "" and the to attribute exactly to the value given here. Example ".bak" will rename the target file by appending the suffix .bak before overwriting it. The override attribute must be set "true" to activate this feature. | no | String - valid globmapper target expression |
blockable | For Windows only, ignored on non-Windows systems: | no | |