Message-ID: <681872869.1061.1406190933168.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1060_415175596.1406190933168" ------=_Part_1060_415175596.1406190933168 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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 the following attributes an
|(not set)||IzPack condition ID for running the job||yes|
|(not set)||IzPack condition ID for running the job||no|
|catch||false||Job runs only in the event of othe= r jobs failing||no|
|final||false||Job runs always, whether previous = jobs succeed or not||no|
The 'catch' and 'final' attributes for a process panel job are used to c= reate a try/catch/final structure for your processes. If a standard job (on= e without catch or final) fails, the process panel will skip the remaining = jobs and exit with a failure. In this event, any jobs marked with the 'catc= h' attribute will run. The jobs marked with the 'final' attributes will alw= ays run regardless of success or failure. In the example above, the &= quot;run on failure" job is only run if one of the "do xyz" = jobs fails. The "run always" job is always run regardless of whet= her there is a previous failure or not.
See the IzPack OS Restrictio= ns tag.
In addition to
<arg> elements, the
ile> element also accepts
<env> elements to se=
t 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 f=
the value supports variable substitution, for example:
_PRODUCT_HOME=3D$INSTALL_PATH</env>. The workingDir attribute for the <executefile> element adds the ability to se=
t 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 i=
n case of failure and in case of success, respectively.
In the above example the job do xyz would be run, and if it ret=
urned with an error, the next button would be greyed out, and the =
button to the previous page would be enabled. If it returned witho=
ut an error, the conditions of the
<onSuccess> elements =
would be checked and the respective action would be taken.
<e= xecuteclass>- 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
ProcessPanel.Spec.xml to include a =
> i've also added a new sub-class of
Processable called =
executeclass. This will run a user-specified class in the cont=
ext of the installer JVM with a single method :
> It can do everything i need and more. In particular, it allows me t= o write a process extension and still be able to provide feedback to the us= er through the feedback panel, and to add new functionality to the installe= r, after its been built.
To use the executeclass facility, you will need to create a jar file wit= h your class and then add it to the installer with the `The Jar Merging Ele= ment`.
See Executing a Java Class with ProcessPanel for details.
<executeForPack>- Only execute the job for certain= packs
This can be be used to run the job only if the pack is enabled. For exam=
ple, the batch file will if either the
ables 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 i=
s pretty much straightforward, you only have to add a line in
Panel.Spec.xml that will tell IzPack the location, where the logfile=
should be stored.
Variable substitution is performed, so you can use
code> as example.
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=
Here's an example:
This will generate a logfile named e.g.
-22-20_43423.log located in
ProcessPanelWorker will write all output that is directed t=
stderr to this file if
Panel.Spec.xml contains the
Please note that this one file is used for storing the complete output o= f all jobs and not a file for each job that is run.