|
|
|
| Next: writing installation xml files Up: izpack-doc Previous: introduction contents |
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.
First go get the latest stable version of IzPack from: http://izpack.org/downloads
If needed download the Latest Java Run Time from Sun's website http://java.sun.com/. You should get the JRE if you intend to ONLY run the installer and get the SDK if you're willing to compile as well.
Don't forget to set up the environment variables:
Once this is done, you can install IzPack using the following command:
java -jar izpack.jar
Where izpack.jar is the latest release you downloaded from IzPack website.
If needed download the Latest Java Run Time from Sun's website http://java.sun.com/. You should get the JRE if you intend to ONLY run the installer, but you should get the SDK if you're willing to compile as well.
You can put them into any script launched at startup if you don't want to have to do it everytime.
For example, .bashrc of your user, so that whenever you'll start a bash console the variables will be set.
To verify that the environment is correct, type SET in the command prompt and check if those variables are set before running any compilation.
=> Then you install IzPack using the following command:
java -jar izpack.jar
By default it will be installed in /usr/local/IzPack.
Therefore you can create two scripts, one for compiling your code and the second to execute the installer.
Compile.sh:
#!/bin/sh
/usr/local/IzPack/bin/compile /yourpath/Install.xml -b /yourpath -o /yourpath/yourjaroutput.jar -k standard
Install.sh:
#!/bin/sh
java -jar yourjaroutput.jar
BUGS and TROUBLESHOOTING
Exception in thread "main" java.lang.InternalError: Can't connect to X11
window server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at
sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:134)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:62)
at java.awt.Font.initializeFont(Font.java:308)
at java.awt.Font.<init>(Font.java:344)
at
com.izforge.izpack.gui.IzPackMetalTheme.createFont(IzPackMetalTheme.java:62)
at
com.izforge.izpack.gui.IzPackMetalTheme.<init>(IzPackMetalTheme.java:52)
at
com.izforge.izpack.gui.IzPackKMetalTheme.<init>(IzPackKMetalTheme.java:59)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at
com.izforge.izpack.installer.GUIInstaller.loadLookAndFeel(GUIInstaller.java:297)
at
com.izforge.izpack.installer.GUIInstaller.<init>(GUIInstaller.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at com.izforge.izpack.installer.Installer.main(Installer.java:47)
Then, it's most probably the fact that in some distribution the console and environment variables are "erased"
when switching between users. So, you can type 'su -' in order to obtain all commands. With 'su -' $DISPLAY variables is erased and all X11 connections is refused. So, a best and fast practice in this way is: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.
(thanks to Bartz Klaus)
Here are the steps needed to develop adn debug IzPack with Eclipse:
BUGS and TROUBLESHOOTING:
If you get this error when running the application
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 :
By default the installer will be made for the current most used version of
the java runtime environment. It is possible to create an installation that
is runable with an older vm version.
What version is used can be detected in the ant properties file that is used
to build izpack. It is [izpackroot]/src/ant.properties.
The value of the property "source" determines the vm version.
If compatibility to older versions is needed, a recompilation of the jar files
of the izpack system should be done. For this the sources of izpack and an ant
installation are needed. the sources of izpack are selectable at installation
time of izpack. Before a recompilation of all can be triggered, the version of
byte code should be changed. This can be done simple by changing the "source"
entry in [izpackroot]/src/ant.properties to the needed value. The
recompilation should be performed with the current most used vm version
because there are classes of it referenced in the izpack code. Usage of an
older vm version at installation time will be possible because the classes of
the newer vm version are only used after a vm version check. Of course, some
features of izpack will be missing at using an old vm version. To recompile
izpack go into [izpackroot]/src. Use a current jdk (not jre) for this.
call
ant clean
followed by
ant all
then all jar files in [izpackroot]/lib, [izpackroot]/bin/panels and [izpackroot]/bin/customactions should be recompiled with the selected source version.
|
|
|
| Next: writing installation xml files Up: izpack-doc Previous: introduction contents |
