Usage

Dynamic variables behave like static variables, except that they are evaluated on each panel change and have additional features.

Dynamic variables, like other variables can be used within ${ and } for substitution.

Dynamic variables can get their values from the following sources:

They can be filtered using regular expressions. A particular dynamic variable can be evaluated based on a certain condition.

Attributes common to all types of dynamic variables are:


As dynamic variables almost completely integrate with static IzPack variables, which means they are mapped to a normal IzPack variable, they can be used as direct variables in user input fields. Take care to have stable evaluation conditions after the user entered a value or use checkonce="true" for this purpose to not override the user value after leaving the panel.

Types of Dynamic Variable Assignments

Plain Values

The easiest way to assign a value to a dynamic variable is a plain value.

Using a plain dynamic variable assignment is recognized by using the attribute value in the variable definition.

Specific attributes:

Example:

<dynamicvariables>
    <variable name="previous.version" value="4.3.3"/>
</dynamicvariable>

The above example is functionally equivalent to

<variables>
    <variable name="previous.version" value="4.3.3"/>
</variable>

since there are no replacements used which might be refreshed on a panel change.

Plain Values as Embedded Text

In another addition to normal variables, the value of a variable can be also defined using a nested value element embedding plain text

Example:

To comment out something in a xml file if a certain pack with the ID "mycoolfeature" is not activated, you might alternate between one and the same variable name, which gets assigned different values in different conditions.

<dynamicvariables>

    <variable name="XML_Comment_Start" condition="\!izpack.selected.mycoolfeature">
        <value><\!\[CDATA[<!--]\]></value>
    </variable>
    <variable name="XML_Comment_End" condition="\!izpack.selected.mycoolfeature">
        <value><\!\[CDATA[-->]\]></value>
    </variable>

    <variable name="XML_Comment_Start" value="" condition="izpack.selected.mycoolfeature" />
    <variable name="XML_Comment_End" value="" condition="izpack.selected.mycoolfeature" />

</dynamicvariables>

The condition "izpack.selected.mycoolfeature" is generated automatically when a pack with the ID "mycoolfeature" was specified. You could now use ${XML_Comment_Start} and ${XML_Comment_End} in a file which should be parsed.

For example, there might be an input file test.xml installed to ${INSTALL_PATH}:

<?xml version="1.0"?>
<test>
	<a></a>
	${XmlCommentStart}<b></b>${XmlCommentEnd}
</test>

parsed like this in install.xml:

<parsable targetfile="$INSTALL_PATH/test.xml" encoding="UTF-8"/>

If the pack mycoolfeature would be enabled during the installation, the file would look like this at the end:

<?xml version="1.0"?>
<test>
	<a></a>
	<b></b>
</test>

otherwise the <b></b> element would be commented out:

<?xml version="1.0"?>
<test>
	<a></a>
	<!--<b></b>-->
</test>


In the <parsable> tag don't use the type="xml" for this example, because it would replace the characters '<' and '>' in your comment XML elements by '&lt;' and '&gt;' in the resulting output.

Values from Environment Variables

Using a  dynamic variable assignment from an environment variable is recognized by using the attribute environment in the variable definition.

Specific attributes:

<dynamicvariables>
    <variable name="search.path" environment="PATH"/>
</dynamicvariables>

The above example is functionally equivalent to

<dynamicvariables>
    <variable name="search.path" value="${ENV[PATH]}"/>
</dynamicvariable>

since there are no replacements used which might be refreshed on a panel change and the environment variable PATH won't change during the runtime of an installation process.

There is one import difference:

  • a variable defined with the environment-attribute is resolved instantly while reading the <dynamicvariables> section. So it can be used as a parameter for subsequent file-attributes in the variable definitions for example.
  • a variable defined with the value="${ENV[PATH]}" attribute will be resolved later, so subsequent usage within <dynamicvariables> will fail.

Values from System Properties

Using a  dynamic variable assignment from an system property is recognized by using the value ${SYSTEM[property]} in the variable definition. For example the following definition will give you the java.io.tmpdir:

<dynamicvariables>
    <variable name="tmpdir" value="${SYSTEM[java.io.tmpdir]}"/>
</dynamicvariable>

Values from Property/Option Files

Dynamic variables can be also assigned from a value in configuration files with key-value pairs, as property files.

Using a  dynamic variable assignment from a certain option or property of an option or property file is recognized by using the attribute file in the variable definition along with the attribute type set to "options" (default if omitted).

Specific attributes:

The attribute type="options" is to be used to make this file parsed as an option file. Separators between the key and value might be for instance '=', ':' including their escaped variants '\=', '\:', where leading and trailing whitespaces are trimmed off.

Example:

<dynamicvariables>

    <variable name="option.1" checkonce="true"
              file="${INSTALL_PATH}/../old_installation/test.properties" type="options"
              key="first.setting"/>

    <variable name="option.2" checkonce="true"
              file="${INSTALL_PATH}/../old_installation/test.conf"
              key="work.dir"/>

</dynamicvariables>

Values from INI Files

It's also possible to assign Windows INI file values to IzPack dynamic variables. INI files are 3-dimensional configuration files with key-value pairs which are divided into several sections, following a certain syntax.

Using a dynamic variable assignment from a certain entry of an INI file is recognized by using the attribute file in the variable definition along with the attribute type set to "ini".

Specific attributes:

Example:

<dynamicvariables>
    <variable name="ini.1" checkonce="true"
              file="C:/Program Files/freesshd/FreeSSHDService.ini" type="ini"
              section="SSH server" key="SSHCMD"/>
</dynamicvariables>

Values from XML Files

Another facility of dynamic variable assignments is reading values from XML files using XPath queries. For the syntax of XPath see XML Path Language (XPath) for more information.

Using a dynamic variable assignment from a certain XML entry in a XML file is recognized by using the attribute file in the variable definition along with the attribute type set to "xml".

Specific attributes:

Example:

<dynamicvariables>

    <variable name="XMLReadTest.1" checkonce="true" ignorefailure="false"
              file="${INSTALL_PATH}/../old_installation/test.xml" type="xml"
              key="/installations/installation[path='/usr/local']/title[@lang='en']/text()"/>

    <variable name="XMLReadTest.2" checkonce="true" ignorefailure="false"
              file="${INSTALL_PATH}/../old_installation/test.xml" type="xml"
              key="//title[@lang='en']/text()"/>

</dynamicvariables>

Values From Configuration Files in an Archive (JAR/ZIP)

All of the above variants of reading a dynamic variable value from a configuration file can be also applied if that configuration files is packaged as an entry into a ZIP or JAR file.

Using a dynamic variable assignment from a certain entry of a configuration file packed into an archive is recognized by using the attributes jarfile or zipfile in the variable definition.

Specific attributes:

Example:

<dynamicvariables>

    <variable name="previous.version" jarfile="${INSTALL_PATH}/${INSTALL_SUBPATH}/libs/config.jar"
              entry="release.properties" type="options"
              key="release.version"
              checkonce="false" ignorefailure="true">
    </variable>

    <variable name="other.stuff" zipfile="${INSTALL_PATH}/${INSTALL_SUBPATH}/libs/misc.zip"
              entry="app.ini" type="ini"
              section="Global Settings" key="AUTOSTART"
              checkonce="true" ignorefailure="true">
    </variable>

</dynamicvariables>

Values from the Windows Registry

Dynamic variable values can be also gathered from Windows registry data.

Using a dynamic variable assignment from a registry entry is recognized by using the attribute regkey in the variable definition.

Specific attributes:

Example:

<dynamicvariables>
    <variable name="RegistryReadTest" checkonce="true"
              regkey="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
              regvalue="Path"/>
</dynamicvariables>

Values from the Output of a Command Execution

Last but not least, a dynamic variable value can be assigned from the output of an external command execution.

Using a dynamic variable assignment from command output is recognized by using the attribute executable in the variable definition.

Specific attributes:

Example 1:

<dynamicvariables>

    <variable name="hostname" checkonce="true"
              executable="hostname"
              type="process"/>

    <variable name="result.value" checkonce="true"
              executable="${INSTALL_PATH}/bin/init.sh"
              type="shell"/>

</dynamicvariables>

Example 2:

<dynamicvariables>

    <variable name="previous.java.version" checkonce="true"
              dir="${INSTALL_PATH}"
              executable="jre/bin/java" stderr="true"
              type="process" ignorefailure="true"
              condition="haveInstallPath+isUpgrade">
      <arg>-version</arg>
      <filters>
        <regex regexp="java version[^\d]+([\d\._]+)" select="\1"/>
      </filters>
    </variable>

</dynamicvariables>

Filtering Values

After straight evaluation, each dynamic variable value can be filtered using predefined filters. Each filter might have a number of attributes to configure its behavior.

Multiple nested filters can be used. The filters will be applied in the order in which they are defined.

Filters are evaluated on each panel change, regardless whether <dynamicvariable checkonce="true"/>, because several variables that might changed are also resolved in a filter.

Filters are embedded in the nested filters element like this:

<dynamicvariables>
   <variable ... <!-- other nested arguments might go here -->
      <filters>
         <filter1 .../>
         <filter2 .../>
         ... <!-- more filters might go here -->
      </filters>
   </variable>
</dynamicvariable>


Regular Expression Filter

After straight evaluation, each dynamic variable's value can be filtered using a Java regular expression. This is done by the nested regex element.

Attributes:

Example:

<dynamicvariables>

	<!--
      Read the property value of release.version in the resource release.properties from the root of the config.jar file.
	  Filter just the version string from the result, if there is one, otherwise return 'none'.
      -->
    <variable name="previous.version" jarfile="${INSTALL_PATH}/${INSTALL_SUBPATH}/libs/config.jar"
              entry="release.properties" type="options"
              key="release.version"
              checkonce="false" ignorefailure="true" condition="upgradecheck">
      <filters>
        <regex regexp="([0-9]+(\.[0-9]+){2})" select="\1" defaultvalue="none"/>
      </filters>
    </variable>

	<!--
      Read the value of the Windows system environment variable %PATH% directly from the Windows registry (can done smarter by ${SYSTEM[PATH]}).
      Filter just the first single path (if there are more separated by the ';' character). If there was a valid value, otherwise return '(unmatched)'.
      -->
    <variable name="RegExTest.Select.Windows" checkonce="true"
              regkey="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
              regvalue="Path">
      <filters>
        <regex regexp="([^;]*)(.*)"
               select="\1"
               defaultvalue="(unmatched)"
               casesensitive="false"/>
      </filters>
    </variable>

	<!--
      Read the value of the Windows system environment variable %PATH% directly from the Windows registry (can done smarter by ${SYSTEM[PATH]}).
      Filter just the first single path (if there are more separated by the ';' character).
	  Prepend and append three plus signs to the resulting value, if there was a valid value, otherwise return '(unmatched)'.
      -->
    <variable name="RegExTest.ReplaceFirst.Windows" checkonce="true"
              regkey="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
              regvalue="Path">
      <filters>
        <regex regexp="([^;]*)"
               replace="+++ \1 +++"
               defaultvalue="(unmatched)"
               casesensitive="false"
               global="false"/>
      </filters>
    </variable>

</dynamicvariables>

Location Filter

After straight evaluation, each dynamic variable value can be filtered to be canonicalized like a filename. This is done by the nested location element. Operating system-specific path conventions are considered when assembling the result.

This means especially the file separator will be converted to that of the target operating system. On Windows, an absolute path is assumed to start with a drive letter followed by a colon, on Unix or MacOSX by a slash.

Furthermore all path parts containing /./ are replaced by the file separator and /dir/../ by the parent directory of dir.

Attributes:

Example:

Assuming all defined conditions are met, the following definition converts all ${previous.wrapper.java.home.canonical}/bin/java not being an absolute path to a canonical path of the form

${INSTALL_PATH}/${previous.wrapper.java.home.canonical}/bin/java

on Unix or

${INSTALL_PATH}\${previous.wrapper.java.home.canonical}\bin\java

on Windows.

<dynamicvariables>
   <variable name="previous.wrapper.java.command.canonical" value="${previous.wrapper.java.home.canonical}/bin/java"
             condition="haveInstallPath+isCompatibleUpgrade+haveWrapperJavaCmd+isSetCanonicalJavaHome">
      <filters>
         <location basedir="${INSTALL_PATH}"/>
      </filters>
   </variable>
</dynamicvariables>

Case Style Filter

Sometimes you need a variable value with all lowercase or all uppercase. This filter has been introduced in version 5.0.0-rc5.

Attributes:

Example:

<dynamicvariables>
   <variable name="var1" value="Some Text" >
      <filters>
         <case style="lower"/>
      </filters>
   </variable>
   <variable name="var2" value="${var1}" >
      <filters>
         <case style="upper"/>
      </filters>
   </variable>
 </dynamicvariables>

will set var1 to "some text" and var2 to "SOME TEXT".