+1 To the plugin architecture in general.
I think we should make it very clear from the beginning what constitutes a plugin and clearly distinguish it from a 'module' (or library).
IMO a plugin provides some clearly defined, self contained functionality which the *user* can/should care about. Plugins can be configured, replaced, added and removed by users. None of these action should leave the system in an unusable state tough. Amongst other things this means, that plugin dependencies should be minimal, optimally there shouldn't be any at all. Furthermore users should not have to care about such dependencies. Whether plugins can be added/removed/configured at runtime is not a primary concern to me. We could maybe even mark plugins as 'dynamic' or 'static'. So a configuration console plugin would be danymic because it could easily attach/detach from the system at runtime. A persistence manager would be more on the static side.
OTOH a module is something which *developers* have to care about. Users shouldn't (need to) care. The Apache commons libs are examples of modules.
Whether we use OSGi or not is an implementation detail. Exposing OSGi as the plugin system to end users seems wrong to me however.
Michael
