Installer and release artifact issues
starksm64 May 25, 2005 6:44 AMTo date the release process has been a simple copying of the ill defined module aspects into the release distribution structure. In working on an installer that allows for selection of specific services + customization of said services. The current build artifacts have several problems for this type of install:
1. The current jars and descriptors are too monolithic. For the jars this means uneccessary size and dependencies. For the descriptors this means service configurations are combined that disallow finer grained installations.
2. The conf/jboss-service.xml has a number of services that significantly increase the minimal footprint. Either this needs to be stripped down to a minimal view (just the hot deployment service), or services that are candidates for static configuration would need a mbean descriptor artifact fragment to allow for inclusion into the conf/jboss-service.xml as part of the install.
3. Some optional services need to be registered before others. The binding service and jsr77 service both operation as listeners of mbean registration events and need to be registered before any services that they should intercept. This is not a functional dependency that can be addressed with a depends tag. These services should really be custom interceptors on the SARDeployer.
4. Customization of the selected services is not a notion that exists in the current release build process. Post installation steps like configuring scoped classloading, call by value invocations, security, a custom datasource, enabling SSL, etc. are all configuration steps that would require the component artifacts to identify the configuration elements that should be transformed along with the variables availble. Something like velocity templatized descriptors along with supported varaibles would need to be declared.
None of this is specific to a gui based installer. The existing testsuite makes use of custom installs of the server based on hard-coded transformations of an existing configuration with overrides of selected service descriptors/config files based on the testsuite/src/resources/test-configs contents. This should be viewed as an installation of selected components with customization of the components.
The issue for the new build is how to support fine grained installation and configuration of a selection of components from both ant driven and gui based installers.