We need you!

Icon

The IzPack documentation needs work, and you are invited to edit it!

Skip to end of metadata
Go to start of metadata

Lifecycle Mappings

The lifecycle mapping to use in a POM launching the IzPack Maven plugin depends on your needs.

In common, there are the following mappings useful with izpack-maven-plugin:

  • pom
    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.
  • izpack-jar
    This is a new mapping coming with IzPack 5.0, reducing the complexity of a POM launching the izpack-maven-plugin.
    It acts similar than the jar lifecycle mapping in Maven except it replaces launching the maven-jar-plugin in the phase package by launching 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 using izpack-jar decreases the complexity of the POM.

For bigger projects with many modules it is a good practise to separate launching of the IzPack Maven Plugin in a separate modules or even more, having one module per application installer to be built.

 

Note

Icon

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

 
Configuration AttributeValue RangeDefault ValueDescription

baseDir

string
${project.build.directory}/staging
Base directory of compilation process

installFile

string
${basedir}/src/main/izpack/install.xml
Location of the IzPack installation file.

comprFormat

default | bzip2

default

Target compression format of the compiled installer jar

comprLevel

integer -1, 0..9

-1
Compression level of the compiled installer jar. Deactivated by default (-1)

outputDirectory

 
${project.build.directory}
Target directory containing the compiled installer jar

mkdirs

true | false
false
Whether to automatically create parent directories of the output file

finalName

  Name of the compiled installer jar
classifier Not setClassifier 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.
enableAttachArtifact
true | false
true
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.

enableOverrideArtifact

true | false
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.

autoIncludeUrl

true | false
false

Whether to automatically include project.url from Maven into the IzPack info header

autoIncludeDevelopers

true | false
false

Whether to automatically include developer list from Maven into IzPack info header

kind

standard | web
standard

Resulting installer type

Example Usage

Example usage of IzPack Maven Plugin (packaging type izpack-jar)

Supporting Goals

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. 

Example usage of Maven Antrun Plugin

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.

Dependency Definition for IzPack and application components

 

To get the dependencies into the staging structure, the Maven copy dependency plugin can be invoked.

 

Copy application components to the staging directory

 

This tells Maven to find the dependencies listed in the <dependencies> section and copy then to the lib folder in the staging directory staging.dir

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.

  • No labels

1 Comment

  1. Target location of the compiled installer jar

    In my opinion this is not a target location. It defines the source location of the installer.xml ? The documentation of the izpack-maven-plugin: Location of the IzPack installation file does make more sense to me. WDYT ?