Hmm, Well, usability aside, it sure changes the code I've written so far :)
Actually, I think it is quite a good approach. IzPack allows any package to be selected on the pack selection panel as long as it's prereqs are satisfied (can't install Tomcat console without installing Tomcat). This all worked fairly well except that we have a condition not directly supported by IzPack which is that the operator is not allowed to configure both Jetty and Tomcat. The installer has override code to prevent the selection of both, but it does not run until the pack selection panel is exited. To some extent, the proposed change would change the semantics of the pack selection screen into something more in accordance with the way IzPack normally works. The changes I'd make to pull this off would be to: 1. Remove the Tomcat/Jetty "Configuration Problem" panel which shows when both are selected. 2. Add check boxes to each related configuration panel asking whether the config should be active. 3. Assume that any packs not selected should be marked false in the config. 4. Allow either Jetty or tomcat to be marked active, but not both. For ease of programming, some static text on the screen could warn of the inability to configure both (hmm, but only if both are to be installed). 5. Do the magic to build the config-store for the installed components. 6. probably lots of other things I have not thought of yet It's not too bad really. It probably is clearer. I'll do it this way. On Monday 19 December 2005 14:06, David Jencks wrote: > On Dec 19, 2005, at 6:52 AM, Erik Daughtrey wrote: > > The next phase of the installer is supposed to only install selected > > components as well as activating them in config.xml. Currently, the > > installer installs all components and modifies config.xml to only > > start those > > selected at install time. > > > > My current plan is to make this an optional feature by adding > > somthing like a > > "Lean install" pack that can be selected. This way folks who > > happen to want > > everything installed, but only some parts configured can have the > > current > > functionality. > > > > Does anyone vehemently disagree with this approach? > > I think the maximum flexibility would come with: > > check boxes on the first page select which configurations are > actually included in the installed server. > check boxes (?? or something) on configuration-specific page controls > whether the configuration is turned on (load="true"/"false") in > config.xml. > > Would this be too hard to use? > > thanks > david jencks > > > -- > > > > Regards, > > > > Erik -- Regards, Erik
