geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "erik daughtrey (JIRA)" <>
Subject [jira] Commented: (GERONIMO-1194) Installer should only install packs(features) selected at install time
Date Fri, 13 Jan 2006 16:45:21 GMT
    [ ] 

erik daughtrey commented on GERONIMO-1194:

Installer Dev Notes

* Built with IzPack ( http://izforge/izpack ), currently based on 3.8.0

* Added images based on work done by EPiC

* Extends IzPack UserInputPanel type: ValidatePackSelections
    - modules/installer-support component
        IzPack requires that any extensions be in the 
        standalone-compiler jar at the time of the 
        installer.  The maven.xml of this project copies 
        the (izpack)standalone-compiler-3.8.0.jar from 
        the maven repo and injects the output of the 
        compile into a copy of the jar and stores it 
        in the local repo as 
        The step which builds the installer 
        (plugins/geronimo-izpack-plugin) has a 
        dependency on this new jar. The assembly step 
        assemblies/j2ee-installer has a dependency on 
        the plugin.

    - added intra-panel port validation
        Up to 7 port port conflicts are reported
        on the "Configuation Checkpoint" panel.
        The limit is imposed by real estate limiateions.

    - added fixes for IzPack auto-install xml processing 
            (need to check 3.8.1 for possible fixes)
        The problem was that the default processing 
        provided by IzPack caused the embedded xml for 
        each panel to be duplicated each time the panel 
        is exited. This was easy to fix for 
        ValidatePackSelections, but required a work-around 
        for the pack selection screen since we don't want 
        to change that portion of IzPack. To fix the 
        pack selection xml the code detects exit from 
        the last panel and gets hold of the ImgPacksPanel 
        xml and a reference to the ImgPacksPanel panel 
        itself via the global InstallData.  The code 
        deletes all the dependent (duplicated) xml 
        and calls the ImgPacksPanel to generate new xml.

    - extended use of JCheckBox (VCheckBox) 
        Added dependency checking for config.xml elements,
        i.e. can't select Jetty web container if 
        J2EE features is selected.  Note that pack (feature) 
        selections already work this way, but this adds 
        the capability to correctly enable/disable config.xml 
        runtime features based on what's installed.

    - Fixed IzPack *feature* of adding/removing 
            checkboxes from panel based on whether the pack 
            is selected. 
        Add/remove caused the checkboxes to walk off the screen
        when the related pack is selected/deselected/selected.  
        The change simply makes unselected pack related fields 
        invisible and vice-versa.

    - Added support for a "configuration complete" panel 
        to display list of port conflicts to repair or "success". 
        The forward button is disabled when conflicts exist. The 
        operator is expected to fix any port conflicts before 

* Added plugin for izpack to build the installer
        - plugins/geronimo-izpack-plugin builds the installer. 
            Assemblies/j2ee-installer uses the 
            plugins/geronimo-assembly-plugin to create the 
            install image which IzPack embeds into the installer 

* IzPack variables
	- Throughout the install, IzPack variables are 
            updated which may be used by IzPack to replace 
            values in "parsable" files (geronimio-izpack.xml).
            Config.xml and configure.xml include variables 
            to be replaced by IzPack after the install image 
            is created. Extension code creates variables 
            for each pack, e.g. ${J2EE.Features}, which are 
            set according to whether the pack is selected 
            or not. 
        - izpack-user-input.xml creates variables like the 
            pack variables, but named like 
            ${J2EE.Features.enable}. These variables are 
            set/reset by the VCheckBoxes based on whether 
            each feature is to be enabled at runtime 
        - The pack variables are used in the project.xml of
            assemblies/j2ee-installer (see config-store 
            handling below) to map configuration archives
            to packs.

* Config-store handling
    - Built module (modules/installer-processing) in 
        org.apache.geronimo.installer.processing called 
        ConfigInstaller which builds the config store after 
        the install image is laid down by the installer. reads 
        to determine which configuration archive (CAR) files 
        should be installed into the configuration.
    - Configure.xml is created by 
        plugins/geronimo-assembly-plugin/plugin.jelly from
        pack information added to the project.xml of 
        assemblies/j2ee-installer and placed into the 
        install image for later processing by 
        ConfigInstaller. The file is marked parsable 
        in geronimo-izpack.xml and the variables of 
        configure.xml are updated at install time 
        after the image is created. Each pack selected 
        will be "configured" into config store.

    - ConfigInstaller is invoked as part of the "processing" 
        capability of IzPack. ConfigInstaller is given a 
        classpath to itself( copied to var/temp since it's
        not needed after install), xerces and the parser APIs.

    - ConfigInstaller builds its own classloader based on 
        all jars in the install image to allow it to call "org.apache.geronimo.plugin.assembly.LocalConfigInstaller"
        to do the actual install of each config.

    - Since ConfigInstaller is a module and there 
        is a dependency on a plugin, reflection is used to 
        invoke the LocalConfigInstaller to eliminate build
        dependencies.  It would be nice to move the brunt of 
        LocalConfigInstaller into a module at some point 
        to allow easier access.

    - All this aside, reflection is necessary to allow 
        the classloader to work anyway. Any direct dependency 
        in the code can wreck the ability of the class loader 
        to load off the path built by finding the jars in the 
        install image. For this reason, reflection is also 
        used internally by the ConfigInstaller to load parts 
        of itself (ConfigWorker) allowint ConfigWorker and
        LocalConfigInstaller to find the classes needed to 
        resolve dependencies contained within the configuration 
        archives being installed.

* Config.xml handling
    - Throughout the install, variables are set which may 
        be used by IzPack for parsable files. As mentioned above.  
        Variables are set to be parsed into config.xml by IzPack.
        The variables are basically set by the panel selections 
        for "active at runtime" for each configurable item.


> Installer should only install packs(features) selected at install time
> ----------------------------------------------------------------------
>          Key: GERONIMO-1194
>          URL:
>      Project: Geronimo
>         Type: Improvement
>   Components: installer
>     Versions: 1.0
>  Environment: Maven, installer runtime
>     Reporter: erik daughtrey
>     Assignee: David Jencks
>      Fix For: 1.1
>  Attachments: installer-ph2-trunk.patch.gz
> DJ: The installer currently works by installing everything in a full
> geronimo install, and not starting the pieces you don't want.  This is
> rather unsatisfactory unless you sell disk space.  The geronimo
> assembly is moving to use of the packaging and assembly plugins, and we
> can leverage that with the installer.  What I am thinking of is
> including a maven repository inside  the installer jar that includes
> everything from a full geronimo install with everything, including all
> the .car files for the configurations.  Then  we can imitate or use the
> assembly plugin to copy the configuration dependencies into the install
> target and install the actual configurations.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message