Message-ID: <2090906420.1581.1432939517560.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1580_2124225564.1432939517560" ------=_Part_1580_2124225564.1432939517560 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In IzPack all of the actual work of installing an application is done in= panels. The IzPack framework is primarily there to support the operation o= f the panels and to manage the navigation through the installation process.= This enables a user to decide which operations are carried out during an i= nstallation and the order in which they are carried out, simply by listing = the appropriate panels in the desired order.
As far as extending the functionality of IzPack is concerned, the result= of this design is that new functionality can be integrated by adding new p= anels to the framework and then listing them in the install spec.
To get started with writing your own panels, it is best to place all the= IzPack code into a separate working directory, from where you can compile = it. Then try to compile the code as is and get that to work.
The next step would be to have a look at another panel implementation, s=
o you can see how things are done. Make sure you look at the less complicat=
ed panels, as the panels with advanced features will only be confusing. All=
the code for building UI and such, only detracts from the essentials of wh=
at a panel needs to do. This means that you shouldn't start with
anel is probably a much better choice at this stage. The source=
code for panels is located at:
You will find that all panels are derived from
; do the same thing with your new panel. Please note that the
Panel class itself is located in the
ack.installer package but your panels need to belong to
Once you have a successful compilation, you must place the compiled resu=
lt of your panel code at a special place, so that the installer compiler ca=
n fetch it when building an installer that uses your panel. Go to:
You will see that there is a subdirectory for each panel. Make a subdire= ctory for your new panel with the exact same name as your panel and place y= our compiled panel code there.
Once this is accomplished, you are ready to use your panel in an install= er. Just list it in the spec file like any other panel, compile and in theo= ry it will show up when running the installer. Once you made it this far, y= ou can dig deeper and get going with your specific needs.
Oh, and one other thing: If you think the your code might be useful for = a larger audience, please think about a contribution to IzPack.
One thing many developers ask about is how to get access to the variable= substitution system. This is not surprising, because customizing an instal= lation for a particular target environment is one of the most important fun= ctions of an installer and the variable substitution system plays a big par= t in this operation.
You can get access to the variable substitution system through the prote=
is variable is of the type
InstallData, which is in turn =
AutomatedInstallData. The Javadoc documentation=
will give you more details on these classes. Of particular interest in thi=
s context are the methods
Some of the interesting methods in
erFrame that you might want to explore are
lockNextButton(). They allow you =
to block the use of the button to move back to the previous panel and the b=
utton that moves to the next panel respectively. Being able to control the =
availability of these buttons to the user is important if one of your panel=
s performs a task where the effects cannot be undone. If the user would nav=
igate back to the previous panel your installation might get into an unknow=
n or even unstable state. On the other hand, if the operations in one panel=
vitally depend that a task in the previous panel is completed, then you sh=
ould block the use of the next button until that task is completed.
If you need configuration files for your panel you would want to use XML=
for that purpose. To read XML files you should use NanoXML, as it is guara=
nteed to be available at installation time. In fact, all of the IzPack infr=
astructure uses NanoXML to read XML files. First you should read the NanoXM=
L documentation. The documentation is included as PDF file with the IzPack =
distribution, have a look in
/doc/nanoxml. In addition to=
that, the Javadoc-generated class documentation is an excellent resource t=
o get help on NanoXML. And then, there is always the code of other panels t=
o see practical examples. Generally, it is a much simpler matter to use Nan=
oXML then to use the DOM included with the Java distribution, so don't hesi=
tate to explore NanoXML.
If your panel requires any supporting classes that are part of the panel= s package, then you must place the .class files into the same directory wit= h your panel .class file.
It is also possible to have supporting classes that are not part of the =
panels package. In fact, these classes don't even have to be in the
ib/installer.jar. If this is done, they will be available at install=
time. For your first experiments you can simply compile your classes and a=
dd them to the .jar file using the jar tool or a zip utility. However, ulti=
mately it is much easier to use Ant and the IzPack build script to accompli=
sh this task.
Because the existing panels all have a visible GUI and because the term = panel hints at something visible, it is not obvious that a panel does not h= ave to contain any visible GUI to function in this framework.
If you have a task that needs to be performed at a particular step in th=
e installation process, but that does not need any user interaction, you ca=
n implement a panel that is not visible. To implement this, you should firs=
t familiarize yourself with the Javadoc documentation of
orge.izpack.InstallerFrame. In your panel code you get access to the=
right instance of
InstallerFramethrough the protected va=
To begin with, do not configure any UI. In other words, do not set a lay=
out and do not place any GUI elements on your panel. In this context the me=
skipPanel() is what gets the job done. In your&=
panelActivate() method you simply perform your task =
and then call
parent.skipPanel(). This gets the job done =
without the user being aware that there was another panel in the flow.
IzPack uses Maven to do its builds. You should not have to make any chan= ges to the Maven POM but you should review it to be sure that you have incl= uded all of the dependencies that you use.
The two data members are : the install = data (refer to the
InstallData Javadoc reference) an=
d a reference to the parent installer frame.
The methods have the following functionality :
(constructor) : called just after the language sel= ection dialog. All the panels are constructed at this time and then the ins= taller is shown. So be aware of the fact that the installer window is*not= strong> yet visible when the panel is created. If you need to do some = work when the window is created, it is in most cases better do it in <= code>panelActivate.
trueif th= e user is allowed to go a step further in the installation process. Returni= ng
falsewill lock it. For instance the LicencePanel= returns
trueonly if the user has agreed with the l= icense agreement. The default is to return
panelActivateis called when the panel becomes active= . This is the best place for most initialization tasks. The default is to d= o nothing.
makeXMLDatais called to build the automated installe= r data. The default is to do nothing.
panelRootrefe= rs to the node in the XML tree where you can save your data. Each panel is = given a node. You can organize it as you want with the markups you want sta= rting from
panelRoot. It's that simple.
runAutomatedis called by an automated-mode installat= ion. Each panel is called and can do its job by picking the data collected = during a previous installation as saved in
panelRoot = ;by
setInitialFocuswith this method it is possible to se= t a hint which component should be get the focus at activation of the panel= . It is only a hint. Not all components are supported. For more information= see java.awt.Component.requestFocusInWindow or java.awt.Component.requestF= ocus if the VM version is less than 1.4.
getInitialFocusreturns the component which should be= get the focos at activation of the panel. If no component was set, null re= turns.
getSummaryBodythis method will be called from the Su= mmaryPanel to get the summary of this class which should be placed in the S= ummaryPanel. The returned text should not contain a caption of this item. T= he caption will be requested from the method getCaption. If null returns, n= o summary for this panel will be enerated. Default behaviour is to return n= ull.
getSummaryCaptionthis method will be called from the= SummaryPanel to get the caption for this class which should be placed in t= he SummaryPanel. Default behaviour is to return the string given by langpac= k for the key ClassName.summaryCaption.
Additionally, there are some helper methods to simplify grid bag layout = handling and creation of some common used components.
A common way to define language dependant messages for custom panels is&= nbsp;to define a r= esource for custom langpacks.
This appears in the install.xml file and defines a German language pack = for a custom panel.
The id should be written as shown, the src file sub path and name can be= other than in the example. This file should be using the same DTD as the c= ommon langpack.
For each language, a separate file with the ISO3 extension in the id sho= uld be used and the src should point to the corresponding language file.