The goal of this thread is to resume discussion of the installer design. Please comment.

Installer design goals:

1. Make it easy for components to integrate into installer and minimize maintenance down the road.
2. Make installer THE ONLY mechanism to produce product distributions (deprecate ant scripts which produce ZIP distributions by copying files over). I.e. installer will be executed in silent mode, and then output from the installer is just zipped up to produce a ZIP distribution.
3. Promote each component?s ownership of the installation related code. This will need to be done since it's hardly possible for one person to keep up to speed with all product changes so that install doesn't constantly get out of sync.
4. Test suite: update AS and other AS?s dependent products test suites to use installer to generate server configs instead of copying directories.

Monolithic installer (in its own separate project) will not scale well once we add more products to it. There are a number of issues that can be foreseen:

1. Installer project will keep getting bigger and maintenance will start getting out of hand.
2. Monolithic installer design doesn?t promote ownership of the installer code by component teams.
3. Large number of installer project branches will need to be created to incorporate multiple permutations of JEMS product versions (i.e. AS4.0.4 + Portal 2.4 + Seam 1.0, AS4.0.5 + Portal 2.4 + Seam 1.0, etc).
4. Installer?s project descriptor (install.xml) duplicates some information which is available from the build system. For instance, file pack definitions and dependencies between packs can be inferred from Maven?s POM?s and/or component-info.xml files.

Proposed installer design:

1. Installer project will only contain core installer code which is not product specific. I.e., no AS or Portal file packs will be declared in the installer. It should be possible to build JEMS installer by simply specifying which components are to be included.
2. Every component will be eventually responsible for writing and maintaining any install related code and resouces (fragment of the install.xml which defined file packs, fragment of the userInputSpec.xml which defines custom configuration panels, listeners which configure configuration files, and all required resources such as configuration file templates).
3. Master installer build would inspect each component's install descriptor in order to assemble combined izpack project and then compile it to build JEMS installer.
4. Once Maven migration is done, it would be nice to build installer when "mvn package" target is executed. This way building installer would be a step of a project lifecycle. Alternatively, we could have a separate Maven plug-in which generates installer (i.e., "mvn installer:installer"). Maven2 includes a plug-in called Assembly (http://maven.apache.org/plugins/maven-assembly-plugin/howto.html) which can be used to generate distributions but it's way too simple to be used to generate an installer. Assembly only takes care of copying files defined by filesets and zipping 'em up. I've started prototyping Maven plug-in which would generate izpack installer.

Scott mentioned that installer design should not depend on Maven. So ideally it should work even if some components are still using jbossbuild.