The lifecycle mapping to use in a POM launching the IzPack Maven plugin depends on your needs.
In common, the following mappings are useful with izpack-maven-plugin:
This is a standard lifecycle mapping in Maven, intended for just grouping several submodules, but almost not doing any job. The izpack-maven-plugin must be explicitly launched in a phase of your choice.
This is a new mapping coming with IzPack 5.0, reducing the complexity of a POM launching the izpack-maven-plugin.
It behaves like the jar lifecycle mapping in Maven except that rather than launching the maven-jar-plugin in the package phase, it launches the izpack-maven-plugin, instead. This can be used as a snap-in for building installer jars instead of compiled jars from Java code, especially combined with the features for attaching an IzPack installer a direct or classified Maven artifact to the project.
The izpack-jar packaging type cannot be used in a module compiling Java source code into a Jar file, but is intended to be used in a standalone module just doing the job of assembling and building an installer. This increases the transparency of your project and decreases the complexity of the POM.
For the izpack-jar mapping is important to add the <extensions>true</extensions>. If you don't, Maven will not be able to see this as a valid packaging. See the example usage below.
|Configuration Attribute||Value Range||Default Value||Description|
|Base directory of compilation process|
|Location of the IzPack installation file.|
default | gz | bzip2 | xz | lzma | deflate
Optional compression format for single files defined in <packs>. All files in all packs except those explicitly marked as <pack200/> are automatically added compressed in the given format and uncompressed later when the installer starts. This may significantly decrease the installer size, but take some more time to compile the installer and install the files later.
See also Compressing pack files for more information on this feature.
Since: IzPack 5.1 (has been broken in 5.0)
integer -1, 0..9
|The compression level of the resulting installer jar file.|
This attribute has nothing in common with the compression attribute declared above, which defines compression for single files added in packs, but defines just the compression level of the whole installer jar file itself.
|Target directory containing the compiled installer jar|
true | false
|Whether to automatically create parent directories of the output file|
|Name of the compiled installer jar|
|classifier||Not set||Classifier to add to the artifact generated. If given, the artifact is attachable. Furthermore, the output file name gets -classifier as suffix. If this is not given,it will merely be written to the output directory according to the finalName.|
true | false
|Whether to attach the generated installer jar to the project as artifact if a classifier is specified. This has no effect if no classifier was specified.|
true | false
|Whether to override the artifact file by the generated installer jar, if no classifier is specified. This will set the artifact file to the given name based on outputDirectory + finalName or on output. This has no effect if a classifier is specified.|
true | false
Whether to automatically include project.url from Maven into the IzPack info header
true | false
Whether to automatically include developer list from Maven into IzPack info header
standard | web
Resulting installer type
You may want to include additional goals in your POM in order to get files into the staging area from your src directory and to find dependencies that you need to have packaged with your installer.
Moving source files to your staging area
Since the staging directory is usually a temporary area, your installer project includes a scr (
izpack.dir.app) folder where you create the files required by the IzPack installer and supporting files for your application such as license text files, README, documentation, etc.. You will need to move them to your staging area prior to invoking the IzPack goal to run the compiler.
The Maven Antrun plugin will do this for you.
This will be invoked by asking Maven to run the antrun:run goal. From the command line this is "mvn antrun:run.
The AntRun Plugin Documentation describes the plugin in detail.
Once you have run this goal, verify that all of the files are in the staging directory in the structure that you have described in your installation file.
Collecting your project's dependencies
If your application includes jars that can be specified as Maven dependencies, your POM file can use the Maven dependency plugin to get the latest versions from a Maven repository.
The dependencies must be listed as dependencies in the pom's dependency section.
To get the dependencies into the staging structure, the Maven copy dependency plugin can be invoked.
This tells Maven to find the dependencies listed in the
<dependencies> section and copy then to the
lib folder in the staging directory
It also specifies that the transitive dependencies are not to be copied (since in this case, they have been built into the jars already.
If you get an error resembling "maven-dependency-plugin (goals "copy-dependencies") is not supported by m2e. pom.xml ... Maven Project Build Lifecycle Mapping Problem", you can refer to this stackoverflow article for the fix.