jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <michael.due...@day.com>
Subject Re: [jr3] Plugin architecture
Date Sat, 20 Feb 2010 14:11:02 GMT

+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 
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.


View raw message