Make IzPack installers more modular - add feature interface

Description

We need an approach to decrease the installer size depending on the user's needs and at the same time offer an approach how to add and isolate features which need additional external libraries or other resources. In the past, there have been often blocked good ideas because they would introduce overhead and increase the installer size for all users, not just for those using that idea.

The best way we currently offer are listeners, but they don't separate resources and external libraries. For instance, the ConfigurationInstallerListener for merging configuration files needs to define:

  • the listener in the <listeners> section

  • the resource "ConfigurationActionsSpec.xml" in the <resources> section

  • jdom2.jar, jaxen.jar etc. as <jar> elements

  • mapping/renaming of configuration files when overwriting, for example to *.configbak

The above items could be ideally added as feature, maybe having its descriptor or even source code (Maven module) completely separated.
The IzPack "feature" discussed here should completely replace old-style listeners. All listeners should be written as features and assembled separately, not in the basic elements of install.xml (resources, jar, listeners, packs, ...).

A feature should be defined as one block of XML in install.xml and might consist of:

  • a name

  • an optional set of jar files additionally needed at runtime

  • a optional set of orther binary or text resources additionally needed at runtime

  • additional translations

  • a set of panel implementations

  • prerequisites which might have been check at install time (OS, architecture, JRE, ...)

  • ...

The implementation should then plug into a given API which is still to define. Plugin points could be:

  • execution beforepacks (before any pack is installed)

  • execution beforepack (immediately before files of a certain pack are installed)

  • execution afterpacks after all pack is installed)

  • execution afterpack (immediately after file of a certain pack are installed)

  • execution beforefile (before a file is installed)

  • execution afterfile (after a file has been installed)

  • mapping of file names for installed files

  • the progress bar

  • logging

  • ...

This API should be versioned and stable within one and the same version. An API version might have prerequisites, like the minimum JDK/JRE version supported, increasing the minimum required JDK should increase the API version.
Another consideration is giving features an own classloader, containing the IzPack plus its additional classpath. This feature classpath will not be available in the rest of the IzPack code. This way there can be ensured using of one and the same fully qualified classnames, but with different meaning or different versions between two different features.
There should be a set of standard features available for IzPack built along with IzPack itself

This issue is still an open discussion.
The main goals are clear:

  • make the resulting installers contain exactly what the user needs, without megabytes of overhead

  • make definitions in install.xml more transparent - divide the knowledges between assembling a feature (feature developer) and using a feature.

Environment

None

Assignee

Unassigned

Reporter

René Krell

Impact

None

Components

Fix versions

Priority

High
Configure