[ http://issues.apache.org/jira/browse/GERONIMO-1194?page=comments#action_12362670 ]
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 (geronimo)standalone-compiler-custom-3.8.0.jar. 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 continuing. * 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 jar. * 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 (config.xml). - 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. ConfigInstaller.java reads ${INSTALL_PATH}/var/config/configure.xml 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. --erik > Installer should only install packs(features) selected at install time > ---------------------------------------------------------------------- > > Key: GERONIMO-1194 > URL: http://issues.apache.org/jira/browse/GERONIMO-1194 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
