On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote:
I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it.
Many installers I've seen allow for light version which rely on the network to fetch components, and have a complete version which includes all of the components.
From an automation perspective it would be best not to add more network dependency, so that once we have a distro zip, we can assume that personality configuration will function with-out unexpected failures due to network issues.
Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism?
IMO, the personality bits are simply collections of plugins (perhaps a few non-plugin cars) to be applied to a base installation. I think the concept is complementary with what we have now.
One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state.
Sure, that is a danger... though that danger exists today. I was not suggesting any specific implementation, but one solution would be to ship all of the extra components for personalities in a different repository dir, then the personality application tool would install from one repo to another.
But, really, we probably need to create some mechanism to classify types of plugins, and then warn the user if they are attempting to enable/install a plugin which collides with another plugin already installed. For example, if there a Jetty plugin already installed, trying to install Tomcat would warn strongly that a duplicate "webcontainer" plugin was already installed (and let them install it if they know better than we do).
RPMs do something similar with its 'provides' tag in spec files... so for example, the apache httpd RPM package might provide 'webserver', fnord (another light http server) might also provide 'webserver' and when apache httpd is already installed, attempts to install fnord will barf with a conflict (which can be forced to override).
--jason
