Each <job> may have the following attributes and an <os> attribute:
name given to the job
ID of the IzPack condition that must evaluate to true to run the job
Job runs only in the event of other jobs failing
Job runs always, whether previous jobs succeed or not
Catch and Final jobs
The 'catch' and 'final' attributes for a process panel job are used to create a try/catch/final structure for your processes. If a standard job (one without catch or final) fails, the process panel will skip the remaining jobs and exit with a failure.
In the event of a failure of a normal job, any jobs marked with the 'catch' attribute will run.
If a job fails and there is no 'catch' job, the process panel will skip the remaining jobs and exit with a failure.
The jobs marked with the 'final' attributes will always run regardless of success or failure.
In the example above, the "run on failure" job is only run if one of the "do xyz" jobs fails. The "run always" job is always run regardless of whether there is a previous failure or not.
Controls the behaviour if the file exits with a non-zero exit code.
ask: Prompt the user whether or not to continue.
fail: Do not allow the installation to continue.
Since: IzPack 5.1
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 element 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> children to the <izpack:processing> element, you can 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's 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:
> 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`.
<logfiledir> - Output of the processPanel saved to a log
Output that is written to the ProcessPanel's textarea can be duplicated in an optional logfile. Add a <logfiledir> element to the <izpack:processing> element of the ProcessPanel.Spec.xml to tell IzPack the location, where the logfile should be stored.
Variable substitution is performed, so you can use $INSTALL_PATH for example.
The name of the logfile is not configurable but should fit in most cases. It will be named Install_V<$APP_VER><YYYY><MM><DD><hh><mm><ss>_<RandomId>.log Here's an example: