geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <>
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:46:21 GMT
Hi Joe,

I am having trouble to understand the difference between what you
propose & what has already been done.

Basically, IIUC, you propose to use a plugin for plugin group, with
the attribute of pluginGroup=true to indicate that is a plugin group.
 This is exactly what has been done today, as we don't differenriate
plugin group any other way other than the attribute of pluginGroup.
If I misunderstand you, could you please give a concrete example?

P.S. I think you were shot down by David because of the complexity of
having plugin groups listed as dependencies on the geronimo specific


On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn <> wrote:
> 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.
> Joe

View raw message