IzPack standalone compiler: Custom langpacks

See my first post for a general introduction.

In this post, I discuss how to include custom langpacks in the installer when using the standalone-compiler.jar.

NOTE: The IzPack documentation talks about custom langpacks and how to reference them in your installation file. However, these langpacks are limited, and do not provide the ability to customize all the text strings used by an IzPack-based installer and uninstaller.

If you use the normal IzPack installation to create your installer, to customize the text strings for a given language, you edit/replace the appropriate XML file under bin/langpacks/installer of the IzPack installation. When creating an installer with IzPack, IzPack copies the files in that location into the the installer jar created, and if an uninstaller is created, they will be included in it also. Which files are copied is based upon the langpack setting(s) in your installation file.

For standalone-compiler.jar usage, all that is required is create the sub-tree bin/langpacks/installer in some directory, and place your customized language files in it.

If you are using the izpack ant task, just include the directory that contains the sub-tree in the classpath when defining the task, and you are good to go. For example:

<taskdef name="izpack"
classname="com.izforge.izpack.ant.IzPackTask">
<classpath>
<pathelement location="${project.build.rc-install}"/>
<pathelement location="${contrib.izpack.dir}/standalone-compiler.jar"/>
</classpath>
</taskdef>

In the above, ${project.build.rc-install} represents the pathname to the directory containing the bin/langpacks/installer sub-tree.

IzPack standalone compiler: Registering custom listeners

IzPack is an open source Java-based software installer. In a project I work on, I use it to create the installer for the project by using the standalone-compiler.jar, and things works pretty good.

One problem though is that for certain customizations tasks, the IzPack documentation is oriented in using an IzPack installation and its tree structure vs standalone-compiler.jar usage. This, post is the start of ways I have found to leverage the customization features of IzPack, but sticking with the standalone-compiler.jar.

Note, I'm working with IzPack 4.3.0, so no guarantees if the methods I describe are applicable to other versions.

In this first post, I figured out how to register a custom listener. In my case, I needed an uninstaller listener. The IzPack documentation for custom action discusses how to implement a listener, but the instructions, and previously noted, is based on working with a regular IzPack installation vs standalone-compiler.jar.

For standalone-compiler.jar, you still need create your listener class, and it must implement the appropriate interface. Since I needed an uninstall listener, I extended com.izforge.izpack.event.SimpleUninstallerListener. For sake of this blog post, my listener class is com.earlhood.izpack.MyUninstallListener.

I compile the class and jar it up in a file called MyInstallListener.jar.

In my IzPack installation file, I add the following tag within the
<listeners> element:

<listener uninstaller="MyUninstallListener"

   jar="${path.to.dir.containing.my.jar}/MyUninstallListener.jar"/>

where ${path.to.dir.containing.my.jar} is the pathname to where the jar file is located.

IMPORTANT: The uninstaller attribute value must be the basename of the class. IzPack scans the jar file to find any .class entry whose basename matches this value. The package name is irrelevant for purposes of IzPack finding the .class file representing the listener.

NOTE: The jar attribute is undocumented. I discovered it when examining the IzPack source.

That is basically it. Of course, I have Ant build scripts to automate the entire build process and use the izpack ant task to create the project installer.