Developers, Developers, Developers! Maksim Sorokin IT Blog


IzPack: Installing Only When Version Was Changed

This post describes a concept of updating a product only when a Maven version of it was changed.

Assume you have a product A, installable by IzPack and built by Maven. When you install product A, you may use RegistryInstallerListener to add entry to the registry. In RegistrySpec.xml (where you provide target key where to store information) you use Maven ${project.version} property. Therefore, when the product A will be installed, the Maven version will be stored in the Registry. Next time you install product A you use read that entry from a registry (here I describe how to do that in IzPack 4. This is out-of-the-box in IzPack 5) and then compare the Maven versions (you may use this post information to create a Maven panel) and determine, whereas to install/update a product.

Product A may also be independent installer, launched from another installer. For instance, if product A installer requires administrative rights, and it is included from product B, which doesn' require administrative right, you would like to avoid UAC as much as possible. So from product B you can check version of product A and determine, whereas you need to launch it.


Panel for Reading Registry in IzPack 4

The panel called RegistryReaderPanel. It can be used in automated installation (silent installations). However, it can be used only once (can be easily extended). Code depends on IzPack COI tools. So COI tools classes need to be delivered together with the panel. Panel is built using Maven, so COI tools are shaded with Maven Shade Plugin. By default we are reading from HKEY_LOCAL_MACHINE registry root. You have to provide an xml file specifying what you want to read and to which variable to store the read value. Here is an example:

  <registry key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\myApp"
      name="DisplayVersion" default="null" variable="myApp.version" />

You may have several registry entries to read multiple keys. name specifies registry key. variable specifies to which variable to store the value. default specifies what should be a default value, when key was not found.

You will also need to provide COI dlls in install.xml:

<native type="3rdparty" name="COIOSHelper.dll" stage="both">
  <os family="windows" />
<native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
  <os family="windows" />

You will need to separate COI package yourself and add it to your Maven repository.

And here is the panel source:izpackExtensions-registryReader


IzPack. Adding 64bit support.

IzPack should work everywhere. However, you have to be aware about several things if you have support for 64bit machines.

First, if you are using COI tools from IzPack (for example if you have your own custom panel that works with registry or using CheckedHelloPanel) you also have to deliver 64bit dll:

  <native type="3rdparty" name="COIOSHelper.dll" stage="both">
    <os family="windows" />
  <native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
    <os family="windows" />

The second thing, if you are using ShortcutPanel, you will also have to deliver 64bit dlls:

  <native type="izpack" name="ShellLink.dll">
    <os family="windows" />
  <native type="izpack" name="ShellLink_x64.dll">
    <os family="windows" />

Windows Service Wrapper Throws an Error?

Windows Service Wrapper throws a strange error? Make sure you have Microsoft .NET Framework Version 2.0 Redistributable Package (x86) or (x64) installed.


GlassFish v3 Windows Service

GlassFish v3 provides a way to create a service. However, one may encounter the following problem:

C:\Sun\glassfishv3\glassfish\bin&gt;asadmin create-service
Error while trying to install GlassFish as a Windows Service.
The return value was: -1073741515.
Usage: asadmin [asadmin-utility-options] create-service [--name ]
        [--serviceproperties ]
        [--force[=]] [--domaindir ]
        [-?|--help[=]] [domain_name]
Command create-service failed.

To fix this problem you need to install Microsoft .NET Framework Version 2.0 Redistributable Package (x86). After installing you don't event need to reboot machine. Just run asadmin create-service again:

C:\Sun\glassfishv3\glassfish\bin&gt;asadmin create-service
Found the Windows Service and successfully uninstalled it.
The Windows Service was created successfully.  It is ready to be started.  Here
are the details:
ID of the service: domain1
Display Name of the service:domain1 GlassFish Server
Domain Directory: C:\Sun\glassfishv3\glassfish\domains\domain1
Configuration file for Windows Services Wrapper: C:\Sun\glassfishv3\glassfish\do
The service can be controlled using the Windows Services Manager or you can use
Windows Services Wrapper instead:
Start Command:  C:\Sun\glassfishv3\glassfish\domains\domain1\bin\domain1Service.
exe  start
Stop Command:   C:\Sun\glassfishv3\glassfish\domains\domain1\bin\domain1Service.
exe  stop
Uninstall Command:  C:\Sun\glassfishv3\glassfish\domains\domain1\bin\domain1Serv
ice.exe  uninstall
Install Command:  C:\Sun\glassfishv3\glassfish\domains\domain1\bin\domain1Servic
e.exe  install

This message is also available in a file named PlatformServices.log in the domai
n's root directory
Command create-service executed successfully.

Locating Startup Folder in Diffirent Windows Versions

Startup folder lets you to launch applications automatically after user logged in. Sometimes one would like to use such functionality and add own startup scripts. But the problem is that this startup folder has different locations in different Windows versions.
For example, in Windows XP: