geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Date Wed, 08 Oct 2008 20:10:38 GMT
I agree that groups of plugins are useful and perhaps necessary from a 
user perspective to help eliminate the clutter.  However, there are 
several ways to provide for those groups.

The way that has thus far been pursued has been creating a new module 
type (is that what you would call it?) of plugingroup.

I had proposed earlier that we just use plugins for this purpose.  We 
can create plugins that do nothing more than aggregate other more 
granular plugins.  We could still keep the attribute of plugin-group 
around as a qualifier to filter out these special "aggregate plugins" 
from among all of the other plugins when necessary (such as when 
assembling a server or to present the user with a non-expert view of 
plugin management).  When I proposed this earlier I was shot down 
because of the classloader creation.  However, since David included a 
change to omit the classloader if there is no plan ... then perhaps 
there is no real inhibitor to this approach now since a plan is not 
needed for an aggregate plugin.

I originally favored this approach because I felt it was the most 
intuitive approach, ensured that the groupings of plugins could 
participate in any scenario that a plugin can participate in today, and 
  had the least code/maintenance impacts.  I think those benefits still 
hold with the possible exception of the classloader change and what that 
may mean when an aggregate plugin is used as a dependency which might 
require a little more effort to resolve.


Lin Sun wrote:
> There is no doubt that framework is useful, but I think most of the
> other plugin groups are useful too (for example web-jetty, web-tomcat,
> or the javaee5-jetty, javaee5-tomcat).   It is almost impossible to
> come up those quickly for a new geronimo user.
> With plugin groups, I can see users pick any of the plugin group(s)
> and plus their applications from their existing server to build a new
> working server easily.
> Some of the plugin groups may sound very simple and small and there
> doesn't seem to be a need for them, for example the jms or jsf plugin
> group.   But for a new user (keep in mind that you guys are geronimo
> experts!!), it is not that obvious to them which modules can get them
> to the jms function.   First, they need to understand activemq is the
> JMS impl in geronimo; Second they need to find out all the modules
> that are jms/activemq related and figure out which ones they need.
> By grouping them together, users can get the function with one click
> or command (specify the plugin group as the plugin to be installed via
> admin console or command line).   Thus I think they add some
> convenience to the user.     I think I am open to remove these type of
> plugin groups if you guys strongly prefer that.
> Lin
> On Wed, Oct 8, 2008 at 12:42 PM, David Jencks <> wrote:
>> I'm also getting worried that the plugin groups are starting to duplicate
>> the plugins and wondering if the concept is providing significant value
>> beyond the framework plugin group.

View raw message