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.
This comment has been removed by the author.
ReplyDelete