The Available Panels
In this section I will introduce the various panels available in IzPack. The usage for most is pretty simple and described right here. The more elaborate ones are explained in more detail in the Advanced Features chapter or in their own chapter. The panels are listed by their class name. This is the name that must be used with the
classname attribute. Please be aware that the classname is Case-Sensitive, meaning that if the case from the install.xml and the founded class file differs the installation will break. In this last case, the installer will Throw an IllegalArgumentException in the compiler if the declared class name in the xml file differs in case from the founded class file.
This panel welcomes the user by displaying the project name, the version, the URL as well as the authors.
This panel allows an HTML document to be used as the "welcome" panel. It operates like the 'HTMLInfoPanel', except that the resource name "HTMLHelloPanel" is used (i.e., "HTMLHelloPanel.info").
This panel welcomes the user also by displaying the project name, the version, the URL as well as the authors.
Additonal on windows the registry will be scanned for an entry which determines that the product is already installed. If so, a dialog will be shown which ask whether to install a second version of the product or not. If you use this panel do not forget to add the `registry feature` into your installation.
InfoPanel and HTMLInfoPanel
This is a kind of 'README' panel. It presents text of any length. The text is specified by the
(HTML)InfoPanel.info resource. Starting from IzPack 3.7.0, variables substitution is allowed. To add an image to the HTMLInfoPanel you simply need to add a ressource to your install.xml with an ID decided by you, then you can call this image by refering it by this same ID.
and in file.html:
Note that variables are being substituted in HTMLINfoPanel (e.g.,
$JINSTALL_PATH will be replaced with the installation path).
You can define multiple HTMLInfoPanel with individual HTML texts by giving them a specific id. The resources are named
LicencePanel and HTMLLicencePanel
Note:* There is a mistake in the name - it should be LicensePanel. In France the word is Licence ... and one of my diploma is a 'Licence' so ...:* -)
Adding images to HTMLLicencePanel works exactly the same way as with HTMLInfoPanel.
These panels can prompt the user to acknowledge a license agreement. They block unless the user selects the 'agree' option. To specify the license agreement text you have to use the
Allows the user to select the packs he wants to install. This panel also allows grouping of packs. Look at
InstallationGroupPanel description to get more details.
This is the same as above, but for each pack a different picture is shown to the user. The pictures are specified using the packImgId attribute for each pack in the installer XML. The initial image will be the image of the first pack that has a packImgId. The image is updated each time the user (de)selects a pack that has a packImgId. Of course it's up to you to specify an image for each pack in your installation with a unique packImgId. For instance if you have 2 packs
documentation (in this order), and you assign both packs a packImgId that is identical to the pack's name then the resource for
core will be
core and the resource for
documentation will be
documentation. The initially shown image will be the resource
core. The supported image formats depend on what your client's JVM supports, but starting from J2SE 1.3, GIF, JPEG and PNG are supported.
This panel is very similar to
PacksPanel, but instead of simple list of available packs, the tree-like list is constructed. By using the
parent attribute of
pack element, one can specify the hierarchy of the tree. This panel supports grouping just like
The result tree contains Base element with no children, and Themes with two children named Black and Red.
This panel allows the user to select the installation path. It can be customized with the following resources (they are text files containing the path) :
TargetPanel.dir.fwhere f stands for the family (
mac, macosx, windows, unix)
TargetPanel.dir: the directory name, instead of the software to install name
TargetPanel.dir.dwhere d is a "dynamic" name, as returned by the JavaTM virtual machine. You should write the name in lowercase and replace the spaces with underscores. For instance, you might want a different setting for Solaris and GNU/Linux which are both Unix-like systems. The resources would be
TargetPanel.dir.sunos, TargetPanel.dir.linux. You should have a Unix-resource in case it wouldn't work though.
The 'ShowCreateDirectoryMessage' variable may be used to suppress the "target directory will be created" dialog. If the 'ShowCreateDirectoryMessage' variable is set to "false" then the dialog will not be shown. If the 'ShowCreateDirectoryMessage' variable is set to "true" or is not specified then the dialog will be shown if the target directory does not exist. See the "Variables Element" section for information on how to specify variables.
The default installation directory is specified as in the TargetPanel (using identical names (TargetPanel... not DefaultTargetPanel...), but will not allow the user to change the installation path. It can be used when software must be installed in a specific location.
You should always have this one as it launches the installation process !
A panel showing text parsed by the variable substitutor. The text can be specified through the
XInfoPanel.info resource. This panel can be useful when you have to show information after the installation process is completed (for instance if the text contains the target path). The font can be set on this text through the optional variable
XinfoPanel.font, and its value is to be formatted consistent with the support provided by java.awt.Font.decode().
In the following example the font size and type are omitted, but they can also be part of the value:
A ending panel, able to write automated installer information. For details see the chapter on 'Advanced Features'.
FinishPanel, but without the automated installer features. It is aimed at making the life easier for end-users who will never encounter the automated installer extra feature.
This panel is used to create desktop shortcuts. For details on using the ShortcutPanel see the chapter 'Desktop Shortcuts'.
This panel allows you to prompt the user for data. What the user is prompted for is specified using an XML file which is included as a resource to the installer.
This panel allows you to compile just installed Java sourcecode. The details for the compilation are specified using the resource
CompilePanel.Spec.xml. The XML file has the following format:
In theory, jobs can be nested but this has not been tested at all. A change to the classpath within a job only affects this job and nested jobs. The classpath should be specified before any files or directories.
The user can change the compiler to use and choose from some default compilation options before compilation is started.
This panel allows you to execute arbitrary files after installation. The details for the compilation are specified using the resource
The XML file has the following format:
Each job may have an
In addition to
<arg> elements, the
<executefile> element also accepts
<env> elements to set variables in the environment of the target process. This can be useful if this process requires some environment variables, such as its installation directory, to work properly. An
<env> element has the following syntax:
<env>variable=value</env>. Note the value supports variable substitution, for example:
<env>MY_PRODUCT_HOME=$INSTALL_PATH</env>. The workingDir attribute for the <executefile> element adds the ability to set the working directory of the process spawned by the ProcessBuilder object, much as <env> elements refer to the environment object of ProcessBuilder.
The ProcessPanel now also supports configurable behaviour for the panel's "Previous" and "Next" buttons. By adding
<onSuccess> childs to the
<processing> element, you define which buttons you want unlocked in case of failure and in case of success, respectively.
In the above example the job do xyz would be run, and if it returned with an error, the next button would be greyed out, and the button to the previous page would be enabled. If it returned without an error, the conditions of the
<onSuccess> elements would be checked and the respective action would be taken.
<executeclass> - Execute Java Classes
It is also possible to execute Java classes from this panel. Here's what this feature author (Alex Bradley) says:
> i've been able to work around my requirements by extending the
ProcessPanelWorker functionality to run user-specified classes. i've extended the DTD of the
ProcessPanel.Spec.xml to include a new element:
> i've also added a new sub-class of
executeclass. This will run a user-specified class in the context of the installer JVM with a single method :
> It can do everything i need and more. In particular, it allows me to write a process extension and still be able to provide feedback to the user through the feedback panel, and to add new functionality to the installer, after its been built.
To use the executeclass facility, you will need to create a jar file with your class and then add it to the installer with the `The Jar Merging Element`.
<executeForPack> - Only execute the job for certain packs
This can be be used to run the job only if the pack is enabled. For example, the batch file will if either the
Executables packs are selected at install time.
<logfiledir> - Output of the processPanel saved to a log
New with version 3.7 is the possibility to tee output that is written to the ProcessPanel's textarea into an optional logfile. Using this feature is pretty much straightforward, you only have to add a line in
ProcessPanel.Spec.xml that will tell IzPack the location, where the logfile should be stored.
Variable substitution is performed, so you can use
$INSTALL_PATH as example.
The name of the logfile is not (yet) configurable but should fit in most cases. It will be named
Here's an example:
This will generate a logfile named e.g.
Install_V1.3_2004-11-08_19-22-20_43423.log located in
ProcessPanelWorker will write all output that is directed to
stderr to this file if
ProcessPanel.Spec.xml contains the
Please note that this one file is used for storing the complete output of all jobs and not a file for each job that is run.
This panel allows the user to select a JDK path. The variable JAVA_HOME does not point to a JDK, else to a JRE also the environment variable points to a JDK. This is not a bug, this is the behavior of the VM. But some products needs a JDK, for that this panel can be used. There is not only a selection of the path else a validation. The validation will be done with the file JDKPath/lib/tools.jar. If JAVA_HOME points to the VM which is placed in the JDK, the directory will be used as default (JAVA_HOME/..). If there is the variable
defined with the value "yes", the panel will be skiped if the path is valid. Additional it is possible to make a version control. If one or both variables
are defined, only a JDK will be accepted which has a version in the range of it. The detection is a little bit pragmatically, therefor it is possible, that the detection can fail at some VMs. The values in the install.xml should be like
If all is valid, the panels isValidated method sets the variable
to the chosen path. Be aware, this variable exist not until the JDKPanel was quitted once. At a secound activation, the default will be the last selection.
This panel will look at the local printers installed and propose a list box with all of them. Once chosen, the variable $SELECTED_PRINTER is set to the user choice.
DataCheckPanel is not for inclusion in an actuall install, but is a debugging resource for developers writing custom panels or code to be included in IzPack. It creates a list of all the variables in InstallData, their values and a list of all packs, indicating which are selected. This list is printed to the console and appears in a scrollable text area on the panel. Put the panel in wherever you want to see any variables in InstallData or a listing of the packs with a line like this in the <panels> section of install.xml:
<panel classname="DataCheckPanel" />
It will automatically give you a full list of all the variables and packs whenever the panel is made active.
This panel gives a summary of all shown panels. The best place for it is just infront of the InstallPanel. Normaly it contains a warning that this is the last panel before installation. The panel contains a scrollable HTML text area to display the summary. The informations are collected from each panel by calling the methods
getSummaryCaption is implemented in
IzPanel with a panel name default text.
getSummaryBody has to be implemented in all panels which should be presented in the summary. If the secound method is not implemented, no summary of this panel will be shown.
Additional it is possible to `log the contents` of the summary panel into a HTML file.
This Panel groups the pack together. A panel which displays the available installGroups found on the packs to allow the user to select a subset of the packs based on the pack installGroups attribute. This panel will be skipped if there are no pack elements with an installGroups attribute. For example
In above example when InstallationGroupPanel is displayed, it contains three radios named Group1, Group2 and Group3. Depending on what user selects, the respective Packs will be displayed in PacksPanel. InstallationGroupPanel will look for a description corresponding to the key "InstallationGroupPanel.description.Group1", "InstallationGroupPanel.description.Group2" etc in installation langpacks and variables and displays this description for each of the Group_i.
You may also define a sortKey in the variables section of the installer.xml to define an alternative sorting. The default sorting is based on the Group Name.
Here is an example for alternative sorting of groups:
By default, your group name (and description) are displayed as-is in the installer. If you want them to be localized, add localized names to your
packsLang.xml resources. The string ID has to be InstallationGroupPanel.group.
Here is an example to localize groups into French (these lines have to be put in your
packsLang.xml_fra resource) :
<str id="InstallationGroupPanel.group.Core" txt="Noyau de l'application" /> <str id="InstallationGroupPanel.description.Core" txt="Fichiers principaux, indispensables au fonctionnement de l'application" /> <str id="InstallationGroupPanel.group.Samples" txt="Fichiers d'exemple" /> <str id="InstallationGroupPanel.description.Samples" txt="Fichiers d'exemples" />
If you want to add html markup to those strings, add
.html at the end of the string id (after the group name).
This panel allows the user to select a path similar to the installation path. Like the installation path, this panel will allow the directory to be created if it does not already exist. It can also be pre-loaded with a path and set to only display if a certain pack is selected using the following variables:
Final path selection can be accessed using the variable "UserPathPanelVariable".
Messages for the UserPathPanel can be customized by creating a custom lang pack and overriding the following values (attribute values wrapped for readability):
This panel is a non-visible panel. It simply loads values from a properties file specified by the variable
load.properties.file and sets them to their respective variables. The panel is designed to allow loading and setting variable values from an external resource at runtime. This maybe useful when values are unknown when the installer is built.
load.properties.file variable is expected to be set before the panel is activated. For instance, the variable maybe specified through a file field on a
UserInputPanel displayed prior to the
LoadPropertiesPanel. Nothing is loaded if the variable is not set when the panel is activated.
An example use case for this panel would be an installer for an enterprise application deployed in multiple environments (e.g. UAT, Production, etc.) with each deployment requiring many environment-specific settings such as database information, application URL, etc. While several
UserInputPanel instances can be used to prompt the user for data, it maybe impossible to set suitable default values for each different environments at the installer build time. Furthermore, it would be inconvenient and error-prone to have the user manually input all values into the panels.
One solution would be to have environment-specific properties files-external to the installer-for each environment. During installation, the user can then specify the path to the properties file on a
UserInputPanel (which sets the
load.properties.file variable) then have the values loaded by a
LoadPropertiesPanel. The loaded values can be used to set the default values in another
UserInputPanel for the user to inspect and modify, if required. Example:
Sample properties file for UAT environment:
Sample properties file for Production environment: