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 <joe.bohn@earthlink.net> 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
>
|