...
The XML file has the following format:
| Code Block | ||
|---|---|---|
| ||
<processing>
<job name="do xyz">
<os family="windows" />
<executefile name="$INSTALL_PATH/scripts/xyz.bat" workingDir="$INSTALL_PATH">
<arg>doit</arg><arg>$variable</arg>
</executefile>
</job>
<job name="do xyz">
<os family="unix" />
<executefile name="$INSTALL_PATH/scripts/xyz.sh">
<arg>doit</arg><arg>$variable</arg>
</executefile>
</job>
</processing>
|
Each job <job> may have the following attributes an <os> attribute.
| Attribute | Default | Description | Mandatory |
|---|---|---|---|
name | (not set) | IzPack condition ID for running the job | yes |
condition | (not set) | IzPack condition ID for running the job | no |
Nested elements to <job>
<os> - Limit Job Execution Environment
See the IzPack OS Restrictions tag.
<executeFile>- Execute Shell Scripts
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 <onFail> and <onSuccess> childs to the <processing> element, you define which buttons you want unlocked in case of failure and in case of success, respectively.
| Code Block |
|---|
<processing>
<job name="do xyz">
<executefile name="$INSTALL_PATH/scripts/xyz.bat">
<arg>doit</arg><arg>$variable</arg>
</executefile>
</job>
<onFail previous="true" next="false" />
<onSuccess previous="true" next="true" condition="mycondition" />
<onSuccess previous="false" next="true" condition="!mycondition" />
</processing>
|
...
> 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:
| Code Block |
|---|
<executeclass name="classname">
<args..../>
</executeclass>
|
> i've also added a new sub-class of Processable called executeclass. This will run a user-specified class in the context of the installer JVM with a single method :
| Code Block |
|---|
run( AbstractUIProcessHandler handler, String[] args]);
|
...
This can be be used to run the job only if the pack is enabled. For example, the batch file will if either the Sources or Executables packs are selected at install time.
| Code Block |
|---|
<processing>
<job name="List files">
<executeForPack name="Sources"/>
<executeForPack name="Executables"/>
<os family="windows" />
<executefile name="$INSTALL_PATH\batch\ListFiles.bat" />
</job>
</processing>
|
...
The name of the logfile is not (yet) configurable but should fit in most cases. It will be namedInstall_V<$APP_VER><YYYY><MM><DD><hh><mm><ss>_<RandomId>.log
Here's an example:
| Code Block |
|---|
<processing>
<logfiledir>$INSTALL_PATH</logfiledir>
<job name="do xyz">
<os family="windows" />
<executefile name="$INSTALL_PATH/scripts/xyz.bat">
<arg>doit</arg><arg>$variable</arg>
</executefile>
</processing>
|
...