You will of course need to depend on IzPack standalone compiler.

Basically, what do you need to do is to have some directory for staging. This is useful, when you want to run some filtering or putting some additional resources from somewhere else to the installer. You can use %TEMP% directory (File.createTempFile(...)) for that. Do not forget to wipe it afterwards!
When you have all your installer resources in some staging directory and you know the direct path to your install.xml you are ready to build a installer:

CompilerConfig compilerConfig = new CompilerConfig(installXmlPath, stagingDirPath, null, targetFilePath);
compilerConfig.executeCompiler();

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>
  <native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
    <os family="windows" />
  </native>

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>
  <native type="izpack" name="ShellLink_x64.dll">
    <os family="windows" />
  </native>

You will need to add AutomationHelper class. Here is how you can do it. Assuming you have custom panel with a name MyPanel, create class MyPanelAutomationHelper in the same package. This class has to extend PanelAutomationHelper and implement PanelAutomation. And then you will have to specify how to run the panel silently.
Basically, you can just repeat all the routine from panelActivate method in MyPanel panel (or if you do not want to repeat yourself, invoke/call MyPanel smartly). But you cannot use UI stuff like emitWarning or emitError. If you need to inform user about something -- write it directly to the output. Silent installer should be silent.

Here is AutomationHelper class for MyPanel panel, which we developed previously:

package com.izforge.izpack.panels;

import java.util.List;

import com.coi.tools.os.win.MSWinConstants;
import com.izforge.izpack.adaptator.IXMLElement;
import com.izforge.izpack.installer.AutomatedInstallData;
import com.izforge.izpack.installer.InstallerException;
import com.izforge.izpack.installer.PanelAutomation;
import com.izforge.izpack.installer.PanelAutomationHelper;

public class MyPanelAutomationHelper extends PanelAutomationHelper implements PanelAutomation {

  @Override
  public void makeXMLData(AutomatedInstallData installData, IXMLElement panelRoot) {
    //
  }

  @Override
  public void runAutomated(AutomatedInstallData installData, IXMLElement panelRoot) throws InstallerException {
    System.out.println("Hello, IzPack");
  }
}

CheckedHelloPanel is an example of interaction with a registry. If you decide to go that way, you will need to do some additional things too besides writing the code.

First of all, you will need to define a COIOSHelper.dll in your install.xml:

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

The second thing is that if you take a look into CheckedHelloPanel code, you will see, that it also uses some com.coi.tools code. You will need to include that into your panel jar too.
Here is the way how we do it. First, we took this com.coi.tools and put it to our maven repository. For each our custom IzPack panel we have a separate maven module nesting some common parent routine (I have already described it in one of the previous posts. Then during package phase of our custom panel code we use Maven Shade Plugin to combine sources of com.coi.tools and our panel code.

The third thing deals with development cycle. If you develop your own custom panel to work with registry using the way , you will need to place dlls inside "izpack" project.
Create src\native folder and copy dlls from bin\native directory in IzPack installation. Then you could use them inside install.xml:

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

First, you have to reference your configuration file from resources section in install.xml file:

<resources>
  <res id="mySpec.xml" src="mySpec.xml" />
</resources>

Then you would need to create such file in your IzPack resources.

And then you can read your file from your custom panel:

@Override
public void panelActivate() {
  InputStream is = ResourceManager.getInstance().getInputStream("mySpec.xml");
...

Moreover, you can read xml using IzPack capabilities. Not that convenient, but anyway:

    String xml = inputStreamToString(is);    // I omit this peace of code, since it is not relevant. "is" -- is InputStream

    IXMLParser parser = new XMLParser();
    IXMLElement rootEl = parser.parse(xml);

    Vector<IXMLElement> els = rootEl.getChildrenNamed("myElements");
    Iterator<IXMLElement> it = els.iterator();
    while (it.hasNext()) {
      IXMLElement el = it.next();

      String myAttribute = el.getAttribute("myAttribute");
      ...

First go and download IzPack. We will use 4.3.3 vesion here.
After installation you will find source directory src\lib in installation location. Import it into Eclipse. Or create a Java project in Eclipse and copy sources afterwards. Obviously, project has some dependencies, so in Java Build Path add all external jars from IzPack installation folder lib. Now you should not have any errors. IzPack code is now browsable.

You can have a maven project for your custom IzPack panels. It is straight forward creation of Maven project, so I will omit it here. I will just assume, that you have a Java project for your panel.

Link you Java project to IzPack libraries, which are located in lib folder of IzPack installation. Please note, that you should not link to imported IzPack project in your Eclipse, because we will need it later on for debugging the panel -- in this case you would have cyclic dependency. Do that in project properties Java Build Path.

According to documentation, panels classes have to be created in com.izforge.izpack.panels. In your project create a package with that name. Now in that package create class MyPanel:

package com.izforge.izpack.panels;

import com.izforge.izpack.installer.InstallData;
import com.izforge.izpack.installer.InstallerFrame;
import com.izforge.izpack.installer.IzPanel;

public class MyPanel extends IzPanel {

  private static final long serialVersionUID = -2686831922771063920L;

  public MyPanel(InstallerFrame parent, InstallData idata) {
    super(parent, idata);
  }

  @Override
  public void panelActivate() {
    System.out.println("Hello, IzPack");
  }
}

Let's create a test IzPack installation, which would use our new panel. Basically, just create "install.xml" file in any folder. I will do that in c:\projects\test25\src\main\resources. Here are the internals of install.xml:

<?xml version="1.0" encoding="UTF-8"?>

<installation version="1.0">

  <info>
    <appname>Test 25</appname>
    <appversion>1.0</appversion>
    <uninstaller write="no" />
    <javaversion>1.6</javaversion>

    <pack200 />
  </info>

  <guiprefs resizable="yes" width="500" height="340">
    <modifier key="allXGap" value="5" />
    <modifier key="allYGap" value="5" />
    <modifier key="paragraphYGap" value="15" />
    <modifier key="useHeadingPanel" value="yes" />
    <modifier key="headingLineCount" value="1" />
    <modifier key="headingFontSize" value="2" />
    <modifier key="headingBackgroundColor" value="0x00ffffff" />
    <modifier key="headingPanelCounter" value="text" />
    <modifier key="headingPanelCounterPos" value="inHeading" />
  </guiprefs>

  <locale>
    <langpack iso3="eng" />
  </locale>

  <panels>
    <panel classname="MyPanel" />
    <panel classname="SimpleFinishPanel" />
  </panels>

  <packs>
    <pack name="main" required="yes">
      <description>Test 25 Installation</description>
    </pack>
  </packs>

</installation>

Now, here is the development flow. You modify the panel code. Then you run IzPack compiler from Eclipse and IzPack installer, also from Eclipse. Just two button clicks!

Here is how you configure it. Navigate to com.izforge.izpack.compiler.Compiler class in imported IzPack project in Eclipse. In menu choose "Run->Profile Configurations..". In "Java Application" on the left create new application entry. In "Main" tab in "Project" choose "izpack" in Main class choose "com.izforge.izpack.compiler.Compiler". In "Arguments" tab write "c:\projects\test25\src\main\resources\install.xml -b c:\projects\test25\src\main\resources -o c:\projects\test25\target\out -h "c:/Program Files/Izpack-4.3.3"", where you specify path to install.xml, where installer jar will be outputed and home path to IzPack installation.

Now, all we need is to tell IzPack, which installer we want to debug. In "Compiler" run configuration we specified the output of Compiler. Right-click "izpack" project and in Build Path specify that jar (which you specified in -o option).

Now you can simply call main class com.izforge.izpack.installer. GUI installer will be launched and you will be able to see all the output in the console. You can run in Debug mode as well.

So again, first modify the code. Then run Compiler and then run Installer.

To start with, I will notice that in installpath you can always use IzPack way of interpreting environmental variables. For example:

<installpath>${ENV[APPDATA]}\3Dfacto\installers\glassfish</installpath>

Next, ordinary IzPack variables to be used in BAT files.
In your silent configuration files you would like to see something like:

<AutomatedInstallation langpack="eng">
   ...
  <com.izforge.izpack.panels.UserInputPanel id="UNKNOWN (com.izforge.izpack.panels.UserInputPanel)">
    <userInput>
      <entry key="myVar" value="%HOMEDRIVE%\location\file.txt"/>
   ...
</AutomatedInstallation>

Here are some ideas which may help you make it work.

Now, when you use ProcessPanel to launch your bat file, you pass a environmental variable inside a variable. Once you realize it, it is easy to make small trick to make everything work. For example, if in silent installation configuration file (in example above), you provide environmental variable to myVar variable. And then you pass it to the bat file with ProcessPanel in processPanelSpec.xml:

<processing>
  <job name="Install configuratorPortal">
    <executefile name="$INSTALL_PATH/script.bat">
      <env>myVar=$myVar</env>
  ...
</processing>

When ProcessPanel launches that bat file, your myVar will be substituted once. But you need to get it substituted two times! What you may do is to simply add shell call command in front of the expression, where myVar is used. In this case, variable will be substituted twice.
However, it will not work in some cases, for example:

call echo hi> %myVar%

or

call if exist %myVar% echo "hi"

What you can do in this case is to use a wrapper. For instance, if you want to call echo command to substitute variable twice:

call echo hi> %myVar%

Then create a helper parameterDumper.bat:

echo off

:: %1 -- what
:: %2 -- where

call echo %~1>> %~2

Include it into installation and simply call that instead:

call "%INSTALL_PATH%\parameterDumper.bat" "hi" "%myVar%"

Then two call commands will be executed and the parameter will be evaluated twice.

As one can see from my previous post it is easy to create a modularized installer with IzPack. However, one may wonder, what about a silent installation of "master" installer? Is there a way to apply auto installation for such "master" installer and make it totally silent? Yes, it is possible.

So as one probably knows, in order to have a silent (auto) installation, one has to provide an auto-install.xml file. We can change our installer easily to do that. For example, during the installation of "master" installer, but just before launching our modularized installers, we can pre-copy auto-install.xml files to specific location. And then in the bat file, where we launch our installers we simply add a path to those auto-install.xml files.

This also can be used when you distribute your installer to some groups of people, who need some specific parameters to be set up accordingly to their setups. What you can do is to ask a system administrator, who knows all the requirements of that group, to modify auto-install.xml files and distribute those files to some specific location on users' machines. And then, when "master" installer will be launched on those machines, it can look whereas auto-install.xml file is present in that specific location. If it is, then launch a silent installation, if it is not, launch normal installation. So dependenciesInstall.bat file from the previous post can be changed to:

echo.
echo -------------------------------------------------------
echo Launching Project1 installer
IF EXIST "locaton_of_auto_config_for_project1" (
  echo Silent install..
  "${INSTALL_PATH}\install\project1-install-standard.jar" "locaton_of_auto_config_for_project1"
) ELSE (
  echo Normal install..
  "${INSTALL_PATH}\install\project1-install-standard.jar"
)

In your install.xml in info section simply specify:

<pack200 />

But be aware, that when your installer is getting bigger and you are using pack200 to compress it, it can take quite a long time!
For instance, if you are carrying other jar files or other installers (I hope to write about modularized installers some time later), building the installer with pack200 can take up to several minutes!