Compressing pack files

This feature has been introduced in IzPack 5.1.

Activating pack compression of any file

As of IzPack 5.1, pack compression of standard compression formats different to Pack200 can be enabled globally either at compiler level, like a Maven plugin or Ant option, or in the <info> section.

Only the raw data of the files packed to the installer is compressed using this method during compiling and automatically uncompressed by the installer.

The following formats are supported:

GZIP ('gz')
BZIP2 ('bzip2')
XZ ('xz') (very good compression rate, but slower)
LZMA ('lzma') (very good compression rate, but slower)
Deflate/ZIP ('deflate')

The default is adding all files uncompressed to the installer jar, where just the native compression of the installer jar itself applies.

Only when enabling one of the above alternative compression formats, there is automatically added the Apache commons-compress code to the installer for handling it.

Enable pack compression in the <info> section

The default pack compression can be defined in the installer descriptor (install.xml) in the <info> section using the <pack-compression-format> format tag.

This setting will be overridden by any definition made in the POM (Maven), Ant task or using the according command line parameter of the compile script (see below).

Example

<info>
    ...
    <pack-compression-format>xz</pack-compression-format>
</info>

Maven builds

For the Maven plugin, there is the <comprFormat> configuration tag, defining the compression algorithm.

POM example

<plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <extensions>true</extensions>
    <configuration>
      ...
      <comprFormat>xz</comprFormat>
    </configuration>
</plugin>

Ant builds

There is an compressionLevel attribute available at the IzPack Ant task for defining the compression algorithm.

Example:

<izpack compressionLevel="xz" ... />

Script builds

For the legacy command line builds, there is an command line argument available for the compile script: -c

Example:

compile.bat -c xz ...

Activating compression of Java bytecode

Java byte code can be compressed by the Pack200 packer dedicated to this file format. Pack200 is defined in the Network Transfer Format JSR 200 Specification.

As of IzPack 5.1, the activation of Pack200 compression has been moved from the <info> to the <packs> section. There can be now added Pack200 compression to dedicated file at pack file level by adding the <pack200> element there, which can be used as nested element to <singlefile>, <file> or <fileset> in the pack definitions.

If this tag is added, all according files are compressed in the Pack200 format for compressing bytecode.

Please note that this format can apply just to JAR files containing Java bytecode. It may fail when trying to compress other input files. It is your choice to add this tag to the correct files.

<pack200> offers several attributes for configuring the packer algorithm. If none of the attributes below is used the default packer settings delivered with the runtime JRE are used implicitly.

For more information on these options see the Pack200.Packer interface documentation.

Attribute name	Description	Values	Default
`effort`	If this attribute is set to a single decimal digit, the packer will use the indicated amount of effort in compressing the archive. Level 1 may produce somewhat larger size and faster compression speed, while level 9 will take much longer but may produce better compression. The special value 0 instructs the packer to copy through the original JAR file directly, with no compression. The JSR 200 standard requires any unpacker to understand this special case as a pass-through of the entire archive. The default is 5, investing a modest amount of time to produce reasonable compression.	0..9	5
`segment-limit`	This attribute is a numeral giving the estimated target size N (in bytes) of each archive segment. As a special case, a value of -1 will produce a single large segment with all input files, while a value of 0 will produce one segment for each class. Larger archive segments result in less fragmentation and better compression, but processing them requires more memory.	number	1000000
`keep-file-order`	If this attribute is set to true, the packer will transmit all elements in their original order within the source archive. If it is set to false, the packer may reorder elements, and also remove JAR directory entries, which carry no useful information for Java applications. (Typically this enables better compression.) The default is true, which preserves the input information, but may cause the transmitted archive to be larger than necessary.	true \| false	true
`deflate-hint`	If this attribute is set to true or false, the packer will set the deflation hint accordingly in the output archive, and will not transmit the individual deflation hints of archive elements. If this attribute is omitted or set to the special string `keep`, the packer will attempt to determine an independent deflation hint for each available element of the input archive, and transmit this hint separately. The default is `keep`, which preserves the input information, but may cause the transmitted archive to be larger than necessary. It is up to the unpacker implementation to take action upon the hint to suitably compress the elements of the resulting unpacked jar. The deflation hint of a ZIP or JAR element indicates whether the element was deflated or stored directly.	true \| false \| keep	keep
`modification-time`	If this attribute is set to the special string `latest`, the packer will attempt to determine the latest modification time, among all the available entries in the original archive or the latest modification time of all the available entries in each segment. This single value will be transmitted as part of the segment and applied to all the entries in each segment (see `segment-limit`). This can marginally decrease the transmitted size of the archive, at the expense of setting all installed files to a single date. If this attribute is set to the special string keep (or omitted), the packer transmits a separate modification time for each input element. The default is keep, which preserves the input information, but may cause the transmitted archive to be larger than necessary. It is up to the unpacker implementation to take action to suitably set the modification time of each element of its output file.	latest \| keep	keep
`strip-line-numbers`	If this attribute is set to true, strip the line number information from the bytecode.	true \| false	false
`strip-local-variables`	If this attribute is set to true, strip local variable names from the bytecode.	true \| false	false
`strip-source-files`	If this attribute is set to true, strip information about the Java source files from the bytecode.	true \| false	false