geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Date Sun, 11 Feb 2007 05:40:39 GMT
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).


View raw message