This page describes proposed JEMS installer re-factoring which can be done along with Maven migration.

Forum thread at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90250

Goals

1. Standartize process of adding new products and components to the installer.

2. Split installer into a significant number of small components (let's call 'em "installer modules") to simplify maintenance.

3. Utilize maven to build the installer.

4. Eliminate installer's dependency on canonical AS distro.

5. Installer refactoring should not depend on full mavenization of all products included (since Maven migration will take relatively long time).

6. Installer build performance should not degrade dramatically.

Design

1. Installer module artifacts will be separate components in the M2 repository.

1. File packs are logical installer components which map to installer artifacts. I.e. web-console, bsh-deployer, jboss-remoting, etc

2. Installer module artifact includes the following:

1. pom.xml (with dependencies on appropriate product components)

2. JAR with resources:

1. Installer module descriptors (component-install-template.xml, userInputSpec.xml, etc). component-install.xml is generated during the installer build from the template using the data from POM.

2. Velocity templates for config file customization

3. Custom user input panels (java classes)

4. Custom action listeners (java classes)

5. Language packs

6. Ant scripts used by custom ant actions

3. Installer modules will have their own versioning. See below for details.

2. JEMS Installer build merges all the installer descriptors from all modules and then executes izpack compiler to build installer jar.

1. Custom Maven2 plug-in can be implemented

    <pack name="web-console"
          installGroups="default,all"
          group="JMX"
          required="no">
      <description>An applet console for the JMX server</description>
      <fileset dir="@{jboss.dist}/server"
               targetdir="$INSTALL_PATH/server/$SERVER_CONFIG">
        <include name="deploy/management/console-mgr.sar/**"></include>
        <include name="deploy/monitoring-service.xml"></include>
        <include name="lib/jboss-monitoring.jar"></include>
        <additionaldata key="web.xml"
                        value="web-console.war/WEB-INF/web.xml.vm"></additionaldata>
        <additionaldata key="jboss-web.xml"
                        value="web-console.war/WEB-INF/jboss-web.xml.vm"></additionaldata>
      </fileset>
      <depends packname="jmx-invoker-service"></depends>
      <depends packname="war-deployer"></depends>
      <depends packname="bsh-deployer"></depends>
      <depends packname="jsr77-service"></depends>
      <depends packname="jboss-aop-deployer"></depends>
    </pack>

Installer module packaging and versioning

It's proposed to have standalone components for the installer modules with their own versioning. The reason is that installer module should not normally be changed every time a new component release is done. So installer module will normally be compatible with multiple component versions.

Plan

1. Prototype: Standalone JBoss Messaging profile could be implemented since Messaging is already being mavenized.

2. Prototype: Generate dependencies between file packs based on dependencies in component pom's

3. Mavenize installer build.

4. Support for both Maven2 repo and JBossBuild repo (for transitioning while projects are being mavenized).

5. Generate dependencies between file packs based on dependencies in component pom's & component-info.xml's.

6. Documentation on how to add a new component to the installer

TODO

1. handling standalone vs embedded into AS install (hibernate, jbpm)

2. handling clustered install

3. what can be obtained from the pom: dependencies, license info.

Concerns

1. Configuration panels which apply to multiple packs. Panels could be product level.