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 Thu, 09 Oct 2008 02:19:19 GMT
Lin Sun wrote:
> 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?

Sorry ... it had been a while since I last looked at this.  I was 
erroneously thinking that there were still fundamental differences 
between plugins and plugingroups (such as when plugingroups were jars 
rather than cars and as a result weren't included in the plugin catalog) 
... but these differences have been eliminated.  The only significant 
difference now is the lack of a classloader (which is really controlled 
by the lack of the plan rather than the presence of the plugingroup 
attribute) and potential dependency issue when a classloader isn't present.

> 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
> plans.
> Lin
> 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