Go back to the documentation index
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 of the panels and to manage the navigation through the installation process. This enables a user to decide which operations are carried out during an installation 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 panels to the framework and then listing them in the install spec. 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 have to contain any visible GUI to function in this framework. There are more details on this subject later on in this chapter.
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, so you can see how things are done. Make sure you look at the less complicated 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 what a panel needs to do. This means that you shouldn't start with `` UserInputPanel`` or ShortcutPanel. HelloPanel is probably a much better choice at this stage. The source code for panels is located at: /src/lib/com/izforge/izpack/panels.
You will find that all panels are derived from IzPanel; do the same thing with your new panel. Please note that the IzPanel class itself is located in the `` com.izforge.izpack.installer`` package but your panels need to belong to com.izforge.izpack.panels. Perhaps you can just copy the code of a panel, remove all the functional stuff and then start filling in your own code. Start with something very simple to begin with, just to see how it works. The implementation is really quite straight forward.
Once you have a successful compilation, you must place the compiled result of your panel code at a special place, so that the installer compiler can fetch it when building an installer that uses your panel. Go to: /bin/panels
You will see that there is a subdirectory for each panel. Make a subdirectory for your new panel with the exact same name as your panel and place your compiled panel code there.
Once this is accomplished, you are ready to use your panel in an installer. Just list it in the spec file like any other panel, compile and in theory it will show up when running the installer. Once you made it this far, you 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 installation for a particular target environment is one of the most important functions of an installer and the variable substitution system plays a big part in this operation.
You can get access to the variable substitution system through the protected variable idata in IzPanel. This variable is of the type InstallData, which is in turn subclassed from AutomatedInstallData. The Javadoc documentation will give you more details on these classes. Of particular interest in this context are the methods `` getVariable()``, setVariable() and getVariableValueMap() in AutomatedInstallData.
Some of the interesting methods in com.izforge.izpack.InstallerFrame that you might want to explore are lockPrevButton() and lockNextButton(). They allow you to block the use of the button to move back to the previous panel and the button 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 panels performs a task where the effects cannot be undone. If the user would navigate back to the previous panel your installation might get into an unknown 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 should 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 guaranteed to be available at installation time. In fact, all of the IzPack infrastructure uses NanoXML to read XML files. First you should read the NanoXML 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 to get help on NanoXML. And then, there is always the code of other panels to see practical examples. Generally, it is a much simpler matter to use NanoXML then to use the DOM included with the Java distribution, so don't hesitate to explore NanoXML.
If your panel requires any supporting classes that are part of the panels package, then you must place the .class files into the same directory with 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 com.izpack... tree. You simply have to ensure that the .class files are located in the proper directory structure inside /lib/installer.jar. If this is done, they will be available at install time. For your first experiments you can simply compile your classes and add them to the .jar file using the jar tool or a zip utility. However, ultimately it is much easier to use Ant and the IzPack build script to accomplish this task.
If you have a task that needs to be performed at a particular step in the installation process, but that does not need any user interaction, you can implement a panel that is not visible. To implement this, you should first familiarize yourself with the Javadoc documentation of com.izforge.izpack.InstallerFrame. In your panel code you get access to the right instance of InstallerFrame through the protected variable parent in IzFrame.
To begin with, do not configure any UI. In other words, do not set a layout and do not place any GUI elements on your panel. In this context the method 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.
If you don't already use Jakarta Ant to support your development work, i highly recommend you have a look at it. It is a great help in organizing practically all routine tasks connected with building and packaging your application. For example, building and getting IzPack ready for distribution is not a straight forward process but with Ant this all comes down to starting a single command. In addition, IzPack provides its own Ant task, which supports the integration of building a complete installer into your regular build scripts. You can find more details about this in the chapter about advanced features. To get a look at Ant you can visit the following link: http://ant.apache.org/index.html.
You can find the Ant build script for IzPack itself at: /src/build.xml
The two data members are : the install data (refer to the InstallData Javadoc reference) and a reference to the parent installer frame.
The methods have the following functionality :
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 to add entries into the common langpacks which are stored in the directory
[IzPackRoot]/bin/langpacks/installer
New with version 3.8 is the possibility to define a resource for custom langpacks. Define e.g.
<resources> ... <res id="CustomLangpack.xml_deu" src="myConfigSubPath/CustomLangpack_deu.xml"/> ... </resources>
in the install.xml file.The id should be written as shown, the file sub path and name can be other than in the example. This file should be using the same DTD as the common langpack. For each language a separate file with the ISO3 extension in the id should be used.
Go back to the documentation index