To begin with, you should know what IZPACK is organized if you want to use
it. Let's go into the directory where you have installed IZPACK on your
machine. There are 3 text files and a set of directories. The most
important for the moment are bin/ doc/ sample/. If you are reading this,
you already know that doc contains this documentation :-)
So let's go into bin/. The icons/ directory contains some
directories for your system, in case you would like an icon to launch a
component of IZPACK . But the most important things you can see in bin
are the compile scripts (in both Unix* and Windows formats).
compile is used to compile a ready-to-go XML installation file from
a command-line context or from an external tool.
Note : these scripts can be launched from anywhere on your system as the
installer has customized these scripts so that they can inform IZPACK of where
it is located.
Now you probably can't wait to build your first installer. So go on open a command-line shell and navigate to sample/. The following should work on both Unix* and Windows systems. For the latter, just change the path separator (slash '/') to a backslash. So type ($ is your shell prompt !) :
$ ../bin/compile install.xml -b . -o install.jar -k standard (installer generation text output here) $ java -jar install.jar
There you are! The first command has produced the installer and the second one did launch it.
Now that you have packaged your first installer, it's time for you to understand
how the whole thing works.
The compilation system (see figure 1.1) is quite modular. Indeed, you can use the compiler in 2 ways :
The compiler takes as its input an XML installation file that describes
(at a relatively high-level) the installation. This file contains
detailed information such as the application name, the authors, the
files to install, the panels to use, which resources to load and much
more (see figure 1.2).
The compiler can generate different kinds of installers, but this information is
not located inside the XML file as it is not were it should be. On the contrary,
this is a compiler parameter.
The compilation options for a command-line installer are the following:
An installer presents its panels to the end-user. For instance, there is
one to select the packages, one to prompt for the license agreement, one
to select the installation path and so on. You have a choice from a
variety of panels to place in the installer. For example, you can choose
between a plain text and a HTML text panel for the license agreement.
Also, if you don't want of the HelloPanel, you just don't
include it.
It is very important to understand that some of the panels may need extra data. For
instance, the license agreement panel needs the license text. A simple approach
to specify such data would have been to add as many XML tags as needed for
each panel. However, this makes the XML file too specific and not easy to
maintain. The approach that has been chosen is to put the data in files and we
call these files resource files. They are specified with a unique XML
tag. This is a much cleaner approach.
You might wonder how your files are packaged. They can be grouped in
packs. For instance, you can have one pack for the core files, one for
the documentation, one for the source code and so on. In this way, your end-users
will have the choice to install a pack or not (provided that the pack they don't
want to install is not mandatory). Inside the jar file (which is a zip file), a
sub directory contains the pack files. Each pack file contains the files that are
part of it. Could we do it simpler ? :-)
There are 2 kinds of installers available :
ant cleanfollowed by
ant allThen all jar files in [IzPackRoot]/lib, [IzPackRoot]/bin/panels and [IzPackRoot]/bin/customActions should be recompiled with the selected source version. Julien Ponge 2005-04-22